I am working on printer driver sample which capture GDI call such as DrvBitBlt(), DrvTextOut() … etc. In DrvBitBlt i am getting ROP4 value as 0XF0F0. It mean to say that we need to use the brush object.
When I read the DrvBitBlt() ROP4 the documentation says:
The low byte specifies a Rop3 that should be calculated if the mask is
one, and the high byte specifies a Rop3 that can be calculated and
applied if the mask is 0.
My question is where the mask value will be present. How go get the mask bit is 0 or 1.
The mask bits come from the third parameter to DrvBitBlt
Related
Title may be wildly incorrect for what I'm trying to work out.
I'm trying to interpret packets I am recieving from a racing game in a way that I understand, but I honestly don't really know what I'm looking at, or what to search to understand it.
Information on the packets I am recieving here:
https://forums.codemasters.com/topic/54423-f1%C2%AE-2020-udp-specification/?tab=comments#comment-532560
I'm using python to print the packets, here's a snippet of the output, which I don't understand how to interpret.
received message: b'\xe4\x07\x01\x03\x01\x07O\x90.\xea\xc2!7\x16\xa5\xbb\x02C\xda\n\x00\x00\x00\xff\x01\x00\x03:\x00\x00\x00 A\x00\x00\xdcB\xb5+\xc1#\xc82\xcc\x10\t\x00\xd9\x00\x00\x00\x00\x00\x12\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00$tJ\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01
I'm very new to coding, and not sure what my next step is, so a nudge in the right direction will help loads, thanks.
This is the python code:
import socket
UDP_IP = "127.0.0.1"
UDP_PORT = 20777
sock = socket.socket(socket.AF_INET, # Internet
socket.SOCK_DGRAM) # UDP
sock.bind((UDP_IP, UDP_PORT))
while True:
data, addr = sock.recvfrom(4096)
print ("received message:", data)
The website you link to is describing the data format. All data represented as a series of 1's and 0's. A byte is a series of 8 1's and 0's. However, just because you have a series of bytes doesn't mean you know how to interpret them. Do they represent a character? An integer? Can that integer be negative? All of that is defined by whoever crafted the data in the first place.
The type descriptions you see at the top are telling you how to actually interpret that series of 1's and 0's. When you see "unit8", that is an "unsigned integer that is 8 bits (1 byte) long". In other words, a positive number between 0 and 255. An "int8" on the other hand is an "8-bit integer", or a number that can be positive or negative (so the range is -128 to 127). The same basic idea applies to the *16 and *64 variants, just with 16 bits or 64 bits. A float represent a floating point number (a number with a fractional part, such as 1.2345), generally 4 bytes long. Additionally, you need to know the order to interpret the bytes within a word (left-to-right or right-to-left). This is referred to as the endianness, and every computer architecture has a native endianness (big-endian or little-endian).
Given all of that, you can interpret the PacketHeader. The easiest way is probably to use the struct package in Python. Details can be found here:
https://docs.python.org/3/library/struct.html
As a proof of concept, the following will interpret the first 24 bytes:
import struct
data = b'\xe4\x07\x01\x03\x01\x07O\x90.\xea\xc2!7\x16\xa5\xbb\x02C\xda\n\x00\x00\x00\xff\x01\x00\x03:\x00\x00\x00 A\x00\x00\xdcB\xb5+\xc1#\xc82\xcc\x10\t\x00\xd9\x00\x00\x00\x00\x00\x12\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00$tJ\x03\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01'
#Note that I am only taking the first 24 bytes. You must pass data that is
#the appropriate length to the unpack function. We don't know what everything
#else is until after we parse out the header
header = struct.unpack('<HBBBBQfIBB', data[:24])
print(header)
You basically want to read the first 24 bytes to get the header of the message. From there, you need to use the m_packetId field to determine what the rest of the message is. As an example, this particular packet has a packetId of 7, which is a "Car Status" packet. So you would look at the packing format for the struct CarStatus further down on that page to figure out how to interpret the rest of the message. Rinse and repeat as data arrives.
Update: In the format string, the < tells you to interpret the bytes as little-endian with no alignment (based on the fact that the documentation says it is little-endian and packed). I would recommend reading through the entire section on Format Characters in the documentation above to fully understand what all is happening regarding alignment, but in a nutshell it will try to align those bytes with their representation in memory, which may not match exactly the format you specify. In this case, HBBBBQ takes up 2 bytes more than you'd expect. This is because your computer will try to pack structs in memory so that they are word-aligned. Your computer architecture determines the word alignment (on a 64-bit computer, words are 64-bits, or 8 bytes, long). A Q takes a full word, so the packer will try to align everything before the Q to a word. However, HBBBB only requires 6 bytes; so, Python will, by default, pad an extra 2 bytes to make sure everything lines up. Using < at the front both ensures that the bytes will be interpreted in the correct order, and that it won't try to align the bytes.
Just for information if someone else is looking for this. In python there is the library f1-2019-telemetry existing. On the documentation, there is a missing part about the "how to use" so here is a snippet:
from f1_2020_telemetry.packets import *
...
udp_socket = socket.socket(family=socket.AF_INET, type=socket.SOCK_DGRAM)
udp_socket.bind((host, port))
while True:
udp_packet = udp_socket.recv(2048)
packet = unpack_udp_packet(udp_packet)
if isinstance(packet, PacketSessionData_V1): # refer to doc for classes / attribute
print(packet.trackTemperature) # for example
if isinstance(packet, PacketParticipantsData_V1):
for i, participant in enumerate(packet.participants):
print(DriverIDs[participant.driverId]) # the library has some mapping for pilot name / track name / ...
Regards,
Nicolas
I need to find packet size sent by each node in OMNeT++. Do i need to set it by myself or is there any way of finding the packet size which is changing dynamically.
Kindly tell me the procedure of finding the Packet size?
I think what you're trying to say is, where can you find the "inherent" size of a packet, for example of one that has been defined in a .msg file, based on "what's in it".
If I'm right: You can't. And shouldn't really want to. Since everything inside an OMNeT++ simulation is... simulation, no matter what the actual contents of a cPacket are, the bitLength property can be set to any value, with no regard to the amount of information stored in your custom messages.
So the only size any packet will have is the size set either by you manually, or by the model library you are using, with the setBitLength() method.
It is useful in scenarios where a protocol header has some fields that are of some weird length, like 3 bits, and then 9 bits, and 1 flag bit, etc. It is best to represent these fields as separate members in the message class, and since C++ doesn't have* these flexible size data types, the representation in the simulation and the represented header will have different sizes.
Or if you want to cheat, and transmit extra information with a packet, that wouldn't really be a part of it on a real network, in the actual bit sequence.
So you should just set the appropriate length with setBitLength, and don't care about what is actually stored. Usually. Until your computer runs out of memory.
I might be completely wrong about what you're trying to get to.
*Yes, there are bit fields, but ... it's easier not having to deal with them.
If you are talking about cPakets in OMNeT++, then simply use the according getter methods for the length of a packet. That is for cases where the packets have a real size set either by you or in your code.
From the cpacket.h in the OMNeT 5.1 release:
/**
* Returns the packet length (in bits).
*/
virtual int64_t getBitLength() const {return bitLength;}
/**
* Returns the packet length in bytes, that is, bitlength/8. If bitlength
* is not a multiple of 8, the result is rounded up.
*/
int64_t getByteLength() const {return (getBitLength()+7)>>3;}
So simply read the value, maybe write it into a temporary variable and use it for whatever you need it.
My NEC microcontroller has a timer controller register 8-bits -
Do, I need to pass 8 in the second parameter of ioremap?
After reading the spec, I got to know the following property of it.
Address |Function Register Name |Symbol |R/W Manipulatable Bits |Default Val
FFFFF590H |TMP0 control register 0 |TP0CTL0 |R/W √ √ |00H
So, I believe that the physical address at which the Timer register TP0CTL0 is mapped is 0xFFFFF590.
Now, I am remapping this register as the following. After reading more description, I got to know that the register is 8-bit in size.
The spec says "The TPnCTL0 register is an 8-bit register that controls the operation of TMPn."
Is this right? I am using the base address as 0xFFFFF590 and the size of this register is 8-bits. Thus, I have given the size as 8-bit. Is it correct? Is the second paramter of ioremap_nocache is in the size of bits? Is my following API is correct? Have I used the parameters correctly in the function - ioremap_nocache.
void *tp0ctl0 = ioremap_nocache(0xFFFFF590, 8);
Next, I am doing the following -
unsigned int val = ioread8(tp0ctl0);
val = 2;
iowrite8(val, tp0ctl0);
Please correct me here. Please let me know, if I am using the API's correctly or not based on the microcontroller information I have.
The size given to ioremap_* is in bytes not bits. The purpose of this function is to map physical address space into kernel virtual address though, so anything greater than zero and less than or equal to the system page size will be equivalent.
Given the information you provided above, ioremap_nocache(0xFFFFF590, 1) would actually be correct. But the effect of "1" versus "8" will be identical since the system page size is (no doubt) larger than both.
In a midi file, if I want to change, say, panning I write
<delta_time> <176(ch1 control change)> <10(pan control)> <value>
This sets panning value to a number between 0 and 127 (msb). For more fine tuning I can also use control message 42 which sets a lsb for the panning. My question is, to set a precise tuning, do I have to repeat the whole message such as:
<delta_time> <176(ch1 control change)> <10(pan control msb)> <value>
<delta_time(0)> <176(ch1 control change)> <42(pan control lsb)> <value>
or can I send
<delta_time> <176(ch1 control change)> <10(pan control)> <value(msb)> <value(lsb)>
Also, what happens if I just send lsb? will it assume msb as 0?
Thanks
Each control-change event is an independent event, so it needs its own delta time, its own status byte, and its own parameter byte(s).
(The status byte can be omitted if it has the same value as the previous one, but this depends only on the status byte's value, and not on whether the events are actually related.)
What happens if you send the MSB message without the LSB message is not clearly specified, and even if it were, you could not be sure that devices would implement it correctly.
To be safe, to change a control with a 14-bit value, send both the MSB and LSB messages, in that order.
I'm just researching this myself. The answer above is not correct, it seems to me. If you reference the official MIDI spec...
(normally you have to pay for the spec but here's a free reprint:)
http://oktopus.hu/uploaded/Tudastar/MIDI%201.0%20Detailed%20Specification.pdf
On page 12, this MSB/LSB scheme is discussed. It says that sending the LSB values is OPTIONAL. I think it's safe to assume that the LSB will be zero if not specified. Furthermore, it clearly states that re-sending the MSB when only the LSB changes is also optional. The only thing that's required is that if you are using LSBs and you change the MSB, you must update the LSB as well.
I think the headline already explains what I want to know.
Is there a possible way to open and save images with 16-bit with Qt? And I don't mean the 3*8=24bit or 4*8=32bit, what is quite the same as a pure 8-bit image, I mean pure 16-bit for R, G and B.
Contrary to what Patrice says, there is no 16 bits per component format in QImage. The most you can get is QImage::Format_ARGB32 at 8 bits per component. Even if you used 8 bits indexed mode, the color tables do not support more than 8 bits per component. Moreover, the QImageIOHandler class works in terms of QImage, so you cannot create a custom image format plug-in to work with 16 bits per color component, unfortunately.
You can use libpng (png++) for that purpose.
QImage::Format not define pure 16 bit but can define 10 bit.
QImage::Format_A2RGB30_Premultiplied (http://doc.qt.io/qt-5/qimage.html), can use RGB 10 bits per channel (0...1).
But if use QImage::setPixel they still use 8 bit per channel for define pixel from QColor.
As others already mentioned, there is no format with 16 bits per component supported in Qt for now.
However there is a request opened to implement this, with a patch attached: https://bugreports.qt.io/browse/QTBUG-45858
Not sure what is the status of this, and if it will get integrated.
Qt5.13 is supported
here is the example
QImage raw((uchar*)byte.data(), 480, 640, QImage::Format_Grayscale16);
raw.save(QString("%1/depth.raw").arg(fileName));
use the flag QImage::Format_Grayscale16