I'm attempting to get my USB driver to enumerate properly on Windows 7, but I'm experiencing some unexpected (to me) behavior.
Everything follows the expected order of operations - that is, Windows issues the following commands:
Get_device_descriptor()
Set_Address()
Get_configuration_descriptor()
At this point, I expect Windows to provide the Set_configuration() command, but instead, it doesn't send anything and my device is shown as being enumerated.
Is there any reason why Windows would not send me the set_configuration command?
In case it will help, below is the configuration descriptor I'm using along with the relevant control flow.
NOTE: my usb analyzer gives me a warning about the wTotalLength field, but it doesn't seem to be correct/relevant
The behavior of USB enumeration routines is implementation specific, and may follow slightly differing paths depending on the driver. Your driver may be looking for additional information before it issues the Set_Configuration command. Have you seen this site. There are several parts. Maybe something there can help.
Related
I am trying to parse some commands to a printer module. it is extracted from a POS machine and I have driven that using Arduino as my CPU to pass image's HEX data to it. now I want to print text. I have found out that there is a universal command set called ESC/POS. but it seems like these commands are already installed on the commercial POS machines available in the market but not on the printer modules themselves. the module that I am using is this
can anyone tell me how to install ESC/POS commands for my setup? here you can see the block diagram of my setup:
As with the previous question, the search results you have shown are only the mechanical units of the printer, no control units there.
Normally, a printer has a control unit that interprets the commands received and performs printing.
If you want to connect the Arduino directly to the mechanical unit of the printer, you have to implement all the functions included in the control unit with the Arduino.
It is a system specific to the mechanical unit used, and there will be no universal and free software.
In other words, it is necessary to create all the interpretation and implementation of ESC/POS commands and the control of the mechanical unit by scratch.
If that is what you want to do, do your best.
Here's an article that does something similar to you. It doesn't seem to be resolved.
Print problem
This article includes the data sheet of the mechanical unit used by the questioner.
LTPZ245-B_J.pdf
If you really want to use this topology, this datasheet will be useful.
SII Thermal Printer Product Catalog 2018-2019
Usually, use the control board(IFD501-01UK/IFD501-01SK) as shown on page 5 of this catalog.
If this is the case, contact SII and we will provide you with a printer driver for Linux.
I don't know if it can be used with Arduino.
Or, even without a device driver, a serial port control board(IFD501-01SK) would make it easy to connect and communicate with the Arduino.
I'd like to get the raw multitouch data from my touchpad in order to.
I've tried using libevdev but my success was limited and I couldn't do what I wanted. I found out about libinput which might be more abstracted, and found out how to use it to automatically get the gestures (for example using libinput-debug-events) but I find them limited and would like to get the raw input (with each finger's movement).
Is there any way to do this with libinput, or not?
I couldn't find any helpful documentation: I found this one but couldn't find any example or route to follow. Actually, I think that I could make myself a way through my problems if I understood how to use these functions, but it's far from clear, and I'm getting in a lot of trouble installing libinput itself (for example, commands like libinput debug-gui aren't recognized by my system).
Any help is appreciated.
Don't know if this helps or not, but on my distro (Ubuntu) I installed libinput-tools.
sudo libinput debug-gui
Also gives me an error:
debug-gui is not a libinput command or not installed.
However,
sudo libinput debug-events
will print out events in the terminal just fine.
I'm installing my driver using dpinst.exe. But before installing my driver I wish to delete all the oem files from inf directory corresponding to my hardware ID.
I want to do this programatically. Please suggest me a way to do this.
**Update :**
I want to do this without device connected as I may pre-install the driver before connecting the device. My device is PNP device.
Use SetupDiEnumDeviceInfo and SetupDiGetDeviceRegistryProperty to match your hardware ID
Use SetupDiOpenDevRegKey and RegQueryValueEx to read the corresponding InfPath
Call SetupUninstallOEMInf
PhilMY has already posted an excellent answer, which is still relevant. However, it is more than ten years old now, so I wanted to update it with more recent/recommended APIs:
Use SetupDiEnumDeviceInfo() and SetupDiGetDeviceRegistryProperty() to match your hardware ID
To get the OEM INF path, SetupDiGetDriverInfoDetail() can be used instead of reading the registry directly
Call DiUninstallDriver() on the resulting INF path (Microsoft recommends using it instead of SetupUninstallOEMInf(). In addition, it returns the needReboot flag, which may be useful in some scenarios.)
#2 is a little tricky as it requires SP_DRVINFO_DATA on input. To acquire it, one typically needs to call SetupDiBuildDriverInfoList() and SetupDiEnumDriverInfo() to iterate through all installed drivers for a particular device (use SPDIT_COMPATDRIVER flag to enumerate 3rd-party drivers).
It has a significant advantage in scenarios when multiple drivers are suitable for the given device, and this approach allows one to choose exactly which driver to uninstall.
Once I've written a sort of a driver for Windows, which had to intercept the interaction of the native display driver with the OS. The native display driver consists of a miniport driver and a DLL loaded by win32k.sys into the session space. My goal was to meddle between the win32k.sys and that DLL. Moreover, the system might have several display drivers, I had to hook them all.
I created a standard WDM driver, which was configured to load at system boot (i.e. before win32k). During its initialization it hooked the ZwSetSystemInformation, by patching the SSDT. This function is called by the OS whenever it loads/unloads a DLL into the session space, which is exactly what I need.
When ZwSetSystemInformation is invoked with SystemLoadImage parameter - one of its parameters is the pointer to a SYSTEM_LOAD_IMAGE structure, and its ModuleBase is the module base mapping address. Then I analyze the mapped image, patch its entry point with my function, and the rest is straightforward.
Now I need to port this driver to a 64-bit Windows. Needless to say it's not a trivial task at all. So far I found the following obstacles:
All drivers must be signed
PatchGuard
SSDT is not directly exported.
If I understand correctly, PatchGuard and driver signing verification may be turned off, the driver should be installed on a dedicated machine, and we may torture it the way we want.
There're tricks to locate the SSDT as well, according to online sources.
However recently I've discovered there exists a function called PsSetLoadImageNotifyRoutine. It may simplify the task considerably, and help avoid dirty tricks.
My question are:
If I use PsSetLoadImageNotifyRoutine, will I receive notifications about DLLs loaded into the session space? The official documentation talks about "system space or user space", but does "system space" also includes the session space?
Do I need to disable the PatchGuard if I'm going to patch the mapped DLL image after it was mapped?
Are there any more potential problems I didn't think about?
Are there any other ways to achieve what I want?
Thanks in advance.
Do I need to disable the PatchGuard if I'm going to patch the mapped DLL image after it was mapped?
To load any driver on x64 it must be signed. With admin rights you can disabled PatchGuard and I personally recommend using DSEO, a GUI application made for this. Or you can bypass PatchGuard by overwriting the MBR (or BIOS), although this is typically considered a bootkit - malware.
Is it possible to listen for a certain hotkey (e.g:Ctrl-I) and then perform a specific action? My application is written in C, will only run on Linux, and it doesn't have a GUI. Are there any libraries that help with this kind of task?
EDIT: as an example, amarok has global shortcuts, so for example if you map a combination of keys to an action (let's say Ctrl-+, Ctrl and +) you could execute that action when you press the keys. If I would map Ctrl-+ to the volume increase action, each time I press ctrl-+ the volume should increase by a certain amount.
Thanks
How global do your hotkeys need to be? Is it enough for them to be global for a X session? In that case you should be able to open an Xlib connection and listen for the events you need.
Ordinarily keyboard events in X are delivered to the window that currently has the focus, and propagated up the hierarchy until they are handled. Clearly this is not what we want. We need to process the event before any other window can get to it. We need to call XGrabKey on the root window with the keycode and modifiers of our hotkey to accomplish this.
I found a good example here.
I think smoofra is on the right track here; you're looking to register a global hotkey with X so that you can intercept keypresses and take appropriate action. Xlib is probably what you want, and XGrabKey is the function, i think.
It's not easy to learn, I'm afraid; I did locate this example that seems useful: TinyWM. I also found an example using Java/JNI (accessing the same underlying Xlib function).
You should look at the source code of xbindkeys.
Xlib programming is pretty arcane, documentation is hard to find, and there are subtle portability issues. You'll be better off copying some battle-hardened code.
One way to do it is to have your application listen on a certain port, or socket file, for incoming requests.
Then you can write a small client application that connects to that port or socket file and sends commands to the running application.
Then you can configure your window manager to bind certain key combinations to launch your small client app.
In UNIX, your access to a commandline shell is via a terminal. This harks back to the days when folks accessed their big shared computers literally via terminals connected directly to the machines (e.g. by a serial cable).
In fact, the 'xterm' program or whatever derivative you use on your UNIX box is properly referred to as a terminal emulator - it behaves (from both your point of view and that of the operating system) much like one of those old-fashioned terminal machines.
This makes it slightly complicated to handle input in interesting ways, since there are lots of different kinds of terminals, and your UNIX system has to know about the capabilities of each kind. These capabilities were traditionally stored in a termcap file, and I think more modern systems use terminfo instead. Try
man 5 terminfo
on a Linux system for more information.
Now, the good news is that you don't need to do too much messing about with terminal capabilities, etc. to have a commandline application that does interesting things with input or windowing features. There's a library, curses, that will help. Lookup
man 3 ncurses
on your Linux system for more information. You will probably be able to find a decent tutorial on using curses online.