UDEV sends out events for CD/DVD drives (I've just tested it with udevadm
) so you should be able to either write a UDEV script or write an upstart script like so:
start on block-device-added
task
script
if [ `$DEV` -eq "/dev/sr0" ]; then
# do something
fi
end script
You might have to be careful about checking its mount status. I'm pillaging this from a similar answer of mine which is a bit more explanatory.
When running udevadm monitor --property --udev
, here is the output I got when putting in a DVD (--property
makes this quite verbose but it lets you know exactly what you're dealing with):
UDEV [2251414.166711] change /devices/pci0000:00/0000:00:1c.1/0000:07:00.0/ata17/host16/target16:0:0/16:0:0:0/block/sr0 (block)
ACTION=change
DEVLINKS=/dev/cdrom /dev/cdrw /dev/disk/by-id/ata-Optiarc_DVD_RW_AD-7240S /dev/disk/by-label/UT2004_DVD /dev/disk/by-path/pci-0000:07:00.0-scsi-0:0:0:0 /dev/dvd /dev/dvdrw
DEVNAME=/dev/sr0
DEVPATH=/devices/pci0000:00/0000:00:1c.1/0000:07:00.0/ata17/host16/target16:0:0/16:0:0:0/block/sr0
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
GENERATED=1
ID_ATA=1
ID_ATA_SATA=1
ID_ATA_SATA_SIGNAL_RATE_GEN1=1
ID_BUS=ata
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_DVD_PLUS_R=1
ID_CDROM_DVD_PLUS_RW=1
ID_CDROM_DVD_PLUS_R_DL=1
ID_CDROM_DVD_R=1
ID_CDROM_DVD_RAM=1
ID_CDROM_DVD_RW=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_DVD=1
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_STATE=complete
ID_CDROM_MEDIA_TRACK_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_FS_LABEL=UT2004_DVD
ID_FS_LABEL_ENC=UT2004_DVD
ID_FS_TYPE=iso9660
ID_FS_USAGE=filesystem
ID_FS_VERSION=Joliet\x20Extension
ID_MODEL=Optiarc_DVD_RW_AD-7240S
ID_MODEL_ENC=Optiarc\x20DVD\x20RW\x20AD-7240S\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_PATH=pci-0000:07:00.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_07_00_0-scsi-0_0_0_0
ID_REVISION=1.00
ID_SERIAL=Optiarc_DVD_RW_AD-7240S
ID_TYPE=cd
MAJOR=11
MINOR=0
SEQNUM=4400
SUBSYSTEM=block
TAGS=:udev-acl:
UDEV_LOG=3
UDISKS_PRESENTATION_NOPOLICY=0
USEC_INITIALIZED=10393360
In the script called by your udev rule, place the while, do, done
snippet below, before your xinput
parameter tweaks.
#!/bin/sh
while [ ! "$(/usr/bin/hcitool info 84:38:35:31:CC:6B >& /dev/null; echo $?)" ]; do
sleep 0.1
done
xinput --set-prop "Mouse of Elios" "Device Accel Constant Deceleration" 5.0
xinput --set-prop "Mouse of Elios" "Device Accel Adaptive Deceleration" 1.0
xinput --set-prop "Mouse of Elios" "Device Accel Velocity Scaling" 3.3
It allows yr script to wait for successive time intervals of 0.1 second, until the mouse is appropriately tethered by Bluetooth and before the xinput --set-prop
cmds kick in.
Note that you have three ways to tweak yr mouse's response to a hand movement.
- Device Accel Constant Deceleration (528): 2.500000
- Device Accel Adaptive Deceleration (529): 1.000000
- Device Accel Velocity Scaling (530): 10.000000
Check this and this out to figure out exactly what those parameter values stand for. In order to satisfactorily modify the "velocity scaling", you'll need to know what your mouse refresh rate is (in Hz). You should find that value on the technical data sheet of your mouse. The Velocity Scaling value is estimated as 1000/refresh_rate_in_Hz
. Thus 3.3 assume a refresh rate of 300Hz, 10 a refresh rate of 100Hz.
Your script seems to bring no change to the default values of:
Device Accel Constant Deceleration (528): 2.500000
Device Accel Adaptive Decelaration (529): 1.000000
as revealed by your xinput --list-props
cmd... Try modifying the value of 2.5 for prop_id 528 and realize that setting prop_id 529 to 1 (default) means "no adaptive acceleration or deceleration".
The udev rule you adapted from Gilles' answer on AU / U&L does not apply strictly to your case. What you need is a rule that kicks in upon "adding" your device, i.e. as soon as its presence first triggers a kernel event. So your udev rule should simply read:
ACTION=="add", SUBSYSTEMS=="input", ATTRS{idVendor}=="____", ATTRS{idProduct}=="____", RUN+="/usr/local/sbin/fixmouse"
where you should replace ____ with your real device's idVendor
and idProduct
. To find that info:
$ udevadm monitor
Connect your BT mouse. Read on the line where "KERNEL" appears, something similar to:
KERNEL[22576.118379] add /devices/pci0000:00/0000:00:1d.7/hci2/2-3/2-3.4/2-3.4:1.0/0003:192F:0916.0004/input/input23/mouse1 (input)
To end monitoring, just type in CTRL+C, then:
$ udevadm info -a -p '/devices/pci0000:00/0000:00:1d.7/hci2/2-3/2-3.4/2-3.4' | grep -e "idVendor" -e "idProduct"
You should obtain 2 or 3 pairs of (idVendor, idProduct) values, depending on how your hardware is put together. My use-case yields:
ATTRS{idVendor}=="192f"
ATTRS{idProduct}=="0916"
ATTRS{idVendor}=="1a40"
ATTRS{idProduct}=="0101"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
Try them in your udev rule in the order they appear. Normally the top most one should be the good one.
To finish, do:
$ sudo mv /home/elios/Documents/FixMouse.sh /usr/local/sbin/fixmouse
$ sudo chown root:root /usr/local/sbin/fixmouse
$ sudo chmod 755 /usr/local/sbin/fixmouse
Hope I got this right. Either way let us know.
Best Answer
An alternative way to run a command if a screen is connected or disconnected
An alternative solution would be to run a tiny background script. Running the script below in the background, I could not measure any increase in processor load whatsoever.
It is an easy an convenient way to run a script, or any other command, whenever a second screen is connected or disconnected.
The example script
xrandr
(mind the space after "connected" to prevent false matches with "disconnected"). Each occurrence represents a connected screen.The script
How to use
connect_screen.py
In the head section, set the command to run on connect ( I set "gedit" as an example, mind the quotes). Also it is possible to set a command on disconnect, likewise. Else leave
disconnect_command = ""
as it is.If you do use a disconnect- command, also uncomment the line:
and comment out the line:
As indicated in the script
If all works fine, add it to your startup applications: Dash > Startup Applications > Add the command:
The
sleep 15
is to make the desktop start up completely before the script starts to run. Just to make sure.EDIT
How to run the script on start up in a "smart" way.
The break of
sleep 15
should work in general, but since the start up time differs per system, It might take some experimenting to find the right break time. With a small addition, the script becomes "smart", and waits for thexrandr
command to be successful before it starts the actual script. If you use the version below, you only need to add the command:to your Startup Applications. Further usage is exactly the same as the version above.
The script