I have two LCD's using Xorg's xinerama feature. Each LCD screen has a touchscreen which are connected to their respective USB lines.
Looking into the '/var/log/messages' file, I see the following:
kernel: input: Analog Resistive as /class/input/input0
kernel: input: USB HID v1.01 Mouse [Analog Resistive] on usb-0000:00:1d.3-1
kernel: input: Analog Resistive as /class/input/input1
kernel: input: USB HID v1.01 Mouse [Analog Resistive] on usb-0000:00:1d.3-2
For some reason, at some point in time the USB bus seems to reset (or something weird) and my two touchscreens get inverted (press the left LCD and the mouse moves on the right and if I press the right LCD the mouse moves on the left).
To try and debug the problem, I tried to write a udev rule to log when my devices get reset/disconnected (or whatever). But it seems as though udev will report full details (product, manufacturer, idProduct, idVendor, etc) on the device when it connects, but gives you nothing but a few bus numbers when it is removed. Why is this?
When I get an ACTION=="remove", KERNEL=="input*" rule, there is no way for me to know which device it is! Does anyone know a way around this?
i'd suggest first thing check udev events on device "remove" event by running e.g. udevadm monitor --kernel --property --subsystem-match=usb and disconnecting your devices in turn and comparing outputs.
Here on a single mouse disconnect i get two events:
KERNEL[6680.737678] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
ACTION=remove
DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0
DEVTYPE=usb_interface
INTERFACE=3/1/2
MODALIAS=usb:v09DAp000Ad0034dc00dsc00dp00ic03isc01ip02in00
PRODUCT=9da/a/34
SEQNUM=2835
SUBSYSTEM=usb
TYPE=0/0/0
KERNEL[6680.739577] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
ACTION=remove
BUSNUM=002
DEVNAME=/dev/bus/usb/002/006
DEVNUM=006
DEVPATH=/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
DEVTYPE=usb_device
MAJOR=189
MINOR=133
PRODUCT=9da/a/34
SEQNUM=2836
SUBSYSTEM=usb
TYPE=0/0/0
You can write your rule invoking a script which should do some job after examining some specific environment variable. A rule may be as simple as
SUBSYSTEM=="usb", ACTION=="remove", RUN+="/usr/local/sbin/usbdevgone.sh"
In your case i'd suggest checking $DEVPATH inside usbdevgone.sh as they should differ for your two otherwise identical devices.
Also you may pass devpath (this is a path in /sys/ filesystem) as an argument to your script like this (see man udev for a list of available substitutions):
SUBSYSTEM=="usb", ACTION=="remove", RUN+="/usr/local/sbin/usbdevgone.sh $devpath"
Do not forget to notify udevd of your new or changed rule with udevadm control --reload-rules
I have run into the same problem in Linux. The information sent on a remove is minimal and cannot be used to uniquely identify the device being removed. I used to use the PHYDEVPATH (which is unique on plug in and unplug for a given machine and USB port), but very unfortunately, that has been deprecated in later versions of udev.
I was writing an application with similars features and I solved the problem implementing a daemon with the only mission of storing the udev_device connected. So when I detect some remove even from the udev_monitor I check for some device missing on the deamon's devices list. That what is missing is the device disconnected. That way I can obtain the data of disconnected devices.
Related
Hey there trusty SO community,
I'm working on a project for my new Samsung "The Frame" TV using a IR remote controller. I am trying to send a "repeating" command (when a button is held continuously). I have no problem sending single commands, I am able to control almost everything I need at this point.
Unfortunately, sending the "power" code on the Samsung Frame TV simply selects the "art" mode. Using the original RF remote, the power button has the same action: "art" mode vs TV mode. In order to turn off the TV with the original RF remote, one has to hold down the power button for a second or two.
So I assume that the IR remote interface would be the same.
I have tried sending all sorts of commands (left arrow, right arrow, volume+, etc...) in repeat mode, but the TV only ever responds to the first command and ignores the "repeat" signals. To be clear, the repeat code blocks are being sent, but for some reason ignored. I was able to validate the repeats are sent correctly using a separate sender and receiver.
I have a working prototype of a custom remote that uses this arduino library
I have also read through this SO thread which is incredibly helpful in understanding the protocol.
I wasn't able to find exact information on the protocol of a repeat command, perhaps there is a bug in the library?
line of code that works for single commands:
IrSender.sendSamsung(0x0707, 0x02, 0); //address, command=pwr, number of repeats = 0
line of code that sends the repeat code
IrSender.sendSamsung(0x0707, 0x02, 10); //address, command=pwr, number of repeats = 10
Thanks in advance,
It turns out that version 3.7.1 and earlier of Arduino-IRremote library implements a "special" repeat handling message. After comparing the repeat protocol to a Samsung Brand remote control, it was found that the repeat messages are actually identical to the single message.
An update was made to Arduino-IRremote in this ticket to fix the Samsung repeat messages.
A release has not yet been created as of typing this, but assume version 3.7.2 or greater will support Samsung correctly.
I am a bit new here, English is not my native, so I am sorry for any possible misspelling.
I have a very odd problem - my Xiaomi Mi Surface Display 34" (XMMNTWQ34 model) monitor buttons act really strange - instead of calling the monitor OSD, pressing any of 4 present buttons tries to switch to another possible input source (this is even not their function!), but no luck: just 3 seconds of the black screen and it turns back to the initial image. Let me explain how I got into this.
I have a monitor named before, which has 4 input ports: 2 DP and 2 HDMI. There is a PC always connected to the monitor via the DP interface (DP1 to be exact). Today I tried to connect a second PC via HDMI to the HDMI1 port. It went totally good, I was able to switch between PCs using a monitor OSD. But I thought it was too long and complicated to press a dozen buttons on OSD just to change an input source, so started to google any other programmatical methods of doing such thing.
Some fact: there are no drivers for this monitor on the Internet (it actually works at full 3440x1440#144 Hz resolution/refresh rate via DP interface without any trouble, but Windows sees it as "Generic PnP Monitor", so I see no way to fix it without a relevant driver).
I have found that any VESA-compatible monitor has the 0x60 parameter, which means exactly "input source", so altering the value of this parameter switches the input source without the need to call an OSD. I have found that the possible values of this 0x60 parameter for my monitor provided by several utilities are: 0x0F, 0x10, 0x11, and 0x12. But setting any of these values got me no luck - the screen just flashed black and nothing more. Moreover, those utilities showed that the current value of the 0x60 parameter was 0x07 - described as "S-Video 1" input source, and it did not change at any made tries. But my monitor does not even have such input ports!
But I discovered a total disaster a bit later - when I tried to switch the input source via OSD, I was not able to call it - any of the 4 buttons on the monitor was causing a black flash and nothing more! So OSD is now totally unavailable! This is madness. I can't enter the OSD, I can't change the input source without turning off any one of 2 connected PCs, I can't do anything which is supposed to be made via OSD. Rebooting and reattaching of every possible thing has no effect - even with 2 PCs being connected to monitor and waiting to enter a BIOS password (no OS loaded whatsoever): pressing any button on the monitor causes only black flash and nothing more, no OSD called. I guess this is a strictly monitor firmware issue because the OSD worked well until yesterday.
I have absolutely no idea how to solve this, I googled this all day long, but no luck. System restore did not change anything. Please help. Thank you all very much.
Same issue after using ControlMyMonitor App. At the time being, i didn't found any solution to get the OSD back. And I didn't found any solution to factory reset the monitor, I don't know if it's possible.
I strongly discourage users to use any kind of VESA com application on this Xiaomi 34 monitor !
Now, the best solution in order to switch inputs, is to disconnect or shutdown one of the computer connected, ans it will switch automaticaly to the only one remaining. (Or use a VESA script...)
I am broadcasting Hello using one Xbee (say A).....Xbee (say B) and Xbee (say C) are receiving a lot of garbage values before and after Hello.
All the baudrates are 9600...where am I going wrong?
It would help if you posted an example of the data you see, perhaps the hex values of each byte.
My guess is that you've configured the modules for "API mode" which wraps payloads with a header (starting with 0x7E, the character ~) and footer. It's useful for "smart" devices because it supports multiple packet types.
Check your settings, and make sure you're using ATAP=0. You can use XCTU to change the settings, or from a terminal use the escape sequence (1 second pause, +++, 1 second pause then module should respond with OK) to enter command mode. In command mode, first set ATAP0 and then ATWR to save the changes.
I've created a keyboard-like with v-usb. I wonder if it's possible to send special command like on my Logitech keyboard to open Calc, increase/decrease volume, shutdown PC, etc.
It ought to be achievable. First you may need to pretend to be a Logitech keyboard, in the event that certain scan codes are only acted on if the keyboard type matches.
Second, you would need to find out what the scan code is for those keys. You might get help at Scan Codes Demystified and USB IDs.
I'm developing on a mobile gsm platform and I need to know the PIN in order to change it. Is there a way to verify if the PIN has a certain value?
I'm looking for the solution that makes use of AT commands since this is the only way to control the gsm modem.
I need this to prevent the use of the SIM card for data transfer, calls etc in personal phones or other devices.
Is there a simple way to find out what the PIN is (highly unlikely) or to check if the PIN is the one from a list of expected values?
Thanks
You cannot extract the pin with the standard command set, AT+CPIN=XXXX will respond with OK if XXXX is the correct pin, otherwise it will generate a CME error - however submitting 3 incorrect attempts can cause the SIM to lock until the PUK code is entered.
If you know the PUK however, you could always change the pin to a known value without needing the original PIN (AT+CPIN again).