Two Questions:
1) Is it possible to send a message to the device and receive all the current input values?
I am trying to receive and send data to the KORG nanoKONTROL2. I found an API for real-time input/output called RtMidi. Receiving data is no issue, but I don't have the state where the sliders and knobs are in when the application starts. I presume, if this could be done, you need to send a message to the device.
There is an RtMidiOut class with sendMessage functionality where you can send data (vector<uchar>) to the device, but I don't know what data to send (I did try with some for loops to see if anything happens, but no luck).
2) Is it possible to turn the button lights on/off? If so, how?
To clarify the second question; I am trying to create a toggle where the light of the button on the device will turn on/off according to the state of the toggle.
Additional Information: The received data exists of 3 unsigned char's where the first value is probably an id, I am not quite sure, the second is the button/slider id and the third is its value.
Source code link to GitHub.
I need to hook globally mouse clicks and block last click if delay between two clicks is less than was set.
I wrote it for windows using WM_MOUSE_LL hook.
I was unable to find any solution for me. Is it even possible to globally block mouse click in X11 ?
Windows full code
As far as I know the standard X11 protocol doesn't allow this. The XInput 2.0 extension might, but I doubt it.. while Windows assumes a single event queue that every program listens to, so that a program can intercept an event and prevent it from being sent down the queue to other listeners, every X11 client has its own independent queue and all clients that register interest in an event receive an independent copy of it in their queue. This means that under normal circumstances it's impossible for an errant program to block other programs from running; but it also means that, for those times when a client must block other clients, it must do a server grab to prevent the server from processing events for any other client.
Which means you can either
use an X server proxy (won't be hard, but will be pretty slower)
or
do it on the input device level. /dev/input/event<n> give you the input events. You can read off the keypresses there and decide if they should propagate further be consumed. Unfortunately there's no real documentation for this, but the header file linux/include/input.h is quite self explanatory.
Is there some way to be notified when my serial device is ready to receive more data?
I am implementing a program that feeds commands to a servo controller over serial using the asynchronous API of QSerialPort. The program works, but it seems that I am experiencing congestion.
In my application I keep a registry of most updated servo position that I wish to synchronize with the controller with as low latency as possible. My attempt at pushing new data to the serial port as quickly as time lets me leads to what I think is a buildup of data that makes the communication break down altogether.
My question is, can I be notified when the serial interface is ready to receive new data somehow while using QSerialPort in asynchronous mode?
The only other option I see is to use synchronous mode and call waitForBytesWritten() But I really don't want to do that.
NOTE: I have studied the serial port examples in the Qt5 documentation carefully, but the example for asynchronous write does not provide the information I need, as it perform a one-shot send before quitting.
You could listen to the signal bytesWritten and check bytesToWrite to determine if the write buffer is empty. Both are inherited from QIODevice.
I am writing network filter kernel extension for os x.
I want to call something like callbacks in kext.
For example in data_in function when I get a tcp packet I want to call this callback from user application. Application changes this packet and I inject it.
How to make this interaction between kext and user application?
First of all, you don't want to block the data_in callback - you should "swallow" the packet, send it to userspace, and when it comes back, re-inject it into the connection.
There are a few ways of exchanging data with userspace processes. The most convenient way for exchanging network packets is probably the kernel control mechanism, which essentially allows you to open a socket connection between a user program and your kext.
Apple used to offer sample source code, "tcplognke" that did something extremely similar, but it seems to have disappeared from their own site. Someone kindly appears to have saved it and is offering it for download - looks OK to me right now, but obviously be cautious about downloading stuff from random websites.
Greetings all,
I'm trying to implement middleware (driver) for an embedded device with generic communication media layer. Not sure what is the best way to do it so I'm seeking an advice from more experienced stackoverflow users:). Basically we've got devices around the country communicating with our servers (or a pda/laptop in used in field). Usual form of communication is over TCP/IP, but could be also using usb, RF dongle, IR, etc. The plan is to have object corresponding with each of these devices, handling the proprietary protocol on one side and requests/responses from other internal systems on the other.
The thing is how create something generic in between the media and the handling objects. I had a play around with the TCP dispatcher using boost.asio but trying to create something generic seems like a nightmare :). Anybody tried to do something like that? What is the best way how to do it?
Example: Device connects to our Linux server. New middleware instance is created (on the server) which announces itself to one of the running services (details are not important). The service is responsible for making sure that device's time is synchronized. So it asks the middleware what is the device's time, driver translates it to device language (protocol) and sends the message, device responses and driver again translates it for the service. This might seem as a bit overkill for such a simple request but imagine there are more complex requests which the driver must translate, also there are several versions of the device which use different protocol, etc. but would use the same time sync service. The goal is to abstract the devices through the middleware to be able to use the same service to communicate with them.
Another example: we find out that the remote communications with the device are down. So we send somebody out with PDA, he connects to the device using USB cable. Starts up the application which has the same functionality as the timesync service. Again middleware instance is created (on the PDA) to translate communication between application and the device this time only using USB/serial media not TCP/IP as in previous example.
I hope it makes more sense now :)
Cheers,
Tom
The thing is how create something generic in between the media and the handling objects. I had a play around with the TCP dispatcher using boost.asio but trying to create something generic seems like a nightmare :). Anybody tried to do something like that? What is the best way how to do it?
I haven't used Boost, but the way I usually handled that kind of problem was to create a Device base class which the server interacts with, and then subclassed it for each device type, and made the subclasses deal with the device oddness. That way, the Device class becomes a definition of your protocol. Also, the Device class would need to be portable, but the subclasses would not.
If you had to get fancier than that, you could use the Factory pattern to create the actual subclassed objects.
As far as actually communicating, I'd see if I could just run one process per Device. If you have to have more than one Device per process, on Linux I'd just use select() and its friends to manage I/O between the various Device instances. I don't know how to do that on Windows; its select only works for sockets, not serial ports or other file-like things.
Other things that come to mind that might be useful include dbus and the MPI (Message Passing Interface) library, though they aren't complete solutions for your problem (dbus doesn't do inter-computer communications, IIRC).
Does this help at all?
EDIT: Needed a formatted response to Tom's reply...
Does your device class contain the communication specific parts? Because that's the thing I wanted to avoid.
The subclasses contain the communication specific parts. That's the whole point of using subclasses here; the generic stuff goes in the base class, and the specifics go in the subclass.
I was thinking about something like this: Say there is a dispatcher specific for media used which creates Connection object for each connection (media specific), Device obj. would be created as well but just a generic one and the Connection would pass the incoming data to Device and the Device would pass the responses back to Connection.
I think that may be a bit complex, and you're expecting a generic Device to deal with a specific Connection, which can get hard to maintain fast.
What I'd recommend is a Device subclass specifically for handling that type of Connection which takes the Connection from the dispatcher and owns it until the connection closes. Then your manager can talk to the generic Device and the Connection can mess with the specifics.
An example: Say you have a temperature sensor USB thingamajig. You have some dispatcher that catches the "USB thing plugged in" signal. When it sees the USB thing plugged in:
Dispatcher creates a USBTemperatureThingConnection.
Dispatcher creates a USBTemperatureDevice, which is a subclass of Device, giving the USBTemperatureThingConnection to the USBTemperatureDevice as a constructor parameter.
USBTemperatureDevice::USBTemperatureDevice(USBTemperatureThingConnection* conn) goes and sets up whatever it needs locally to finish setting up the Connection, then sends a message to the Device Manager saying it has set itself up.
Some time later, the Device Manager wants to set the time on all devices. So it iterates through its list of devices and calls the generic (maybe even abstract) Device::SetTime(const struct timespec_t&) method on each of them.
When it gets to your temperature device, it calls USBTemperatureDevice::SetTime(const struct timespec_t&), since USBTemperatureDevice overrode the one in Device (which was either abstract, i.e. virtual void SetTime(const struct timespec_t&) = 0; or a no-op, i.e. virtual void SetTime(const struct timespec_t&) {}, so you don't have to override it for devices that can't set time). USBTemperatureDevice::SetTime(const struct timespec_t&) does whatever USB Temperature sensor-specific things are needed, using the USBTemperatureThingConnection, to get the time set.
Some time later, the device might send back a "Time Set Result" message, saying if it worked or not. That comes in on the USBTemperatureThingConnection, which wakes up your thread and you need to deal with it. So your USBTemperatureDevice::DealWithMessageFromSensor() method (which only exists in USBTemperatureDevice) dives into the message contents and figures out if the time setting worked or not. It then takes that result, turns it into a value defined in enum Device::ResultCode and calls Device::TimeSetComplete(ResultCode result), which records the result, sets a flag (bool Device::timeComplete) saying the result is in, and then hits a Semaphore or Condition to wake up the Device Manager and get it to check all the Device's, in case it was blocked waiting for all the devices to finish setting time before continuing.
I have no idea what that pattern is called. If pressed, I'd say "subclassing", or "object-oriented design" if I felt grumpy. The "middleware" is the Device class, the DeviceManager, and all their underlings. The application then just talks to the Device Manager, or at most to the generic Device interface of a specific device.
Btw. Factory pattern was planned, each object would run in separate thread :)
Good to hear.
I'm assuming by TCP/IP you mean remote nodes, and by USB, etc. the local devices connected to the same physical box. I think what I'm missing in your explanation is the part that announces the new local devices to the server process ( i.e. the analog of a listening socket) Again, assuming something along the lines of Linux uevent, I would start with the following structure:
Controller: knows correct time, manages event sources, reacts to events
Event source: produces "new/delete device" events, knows its device class
server socket
local device monitor
etc.
Device class: encapsulates device-specific logic and manages/enumerates devices
remote device type (connected socket)
USB device type
USB device version X.Y.Z type
etc.
The high-level protocol is very simple - on receipt or "new device" event, query the "Device class" for time from given device, then update the time on the device. The "Device class" is the driver/translator/bridge that implements the conversion from query/update interface to device-specific commands (network exchange for remote nodes.) It also holds a list of its devices.
This should easily map to a class diagram. Was there something else that I missed?