Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Touchscreen changing usb event device on power on/off

  1. #1
    pkg
    pkg is offline
    Low Bitrate pkg's Avatar
    Join Date
    Apr 2005
    Location
    Arizona
    Posts
    96

    Touchscreen changing usb event device on power on/off

    (was USB devices powering off in Linux)

    I have done some more investigation into my usb touchscreen becoming unresponsive when I turn it off and back on.

    When my PC boots up the usb touchscreen is assigned event1.

    When I power off the touchscreen and power it back on the usb touchscreen is reassigned event3.

    This becomes a problem because my XF86Config-4 file has the CorePointer set to Device "/dev/input/event1". When the device changes X can no longer use the usb touchscreen because the device is now "/dev/input/event3".

    Does anyone know if there is a way to either always assign the same event # to a device, or to set X to use multiple Devices for the same pointer (two "Device" settings in the same pointer will just use the first)? Or maybe I am overlooking something?

    Thanks
    -pkg

    Check out my tC: http://publicjestering.com/tc
    Check out my site: http://publicjestering.com

  2. #2
    Newbie
    Join Date
    Dec 2004
    Posts
    48
    Quote Originally Posted by pkg
    (was USB devices powering off in Linux)

    I have done some more investigation into my usb touchscreen becoming unresponsive when I turn it off and back on.

    When my PC boots up the usb touchscreen is assigned event1.

    When I power off the touchscreen and power it back on the usb touchscreen is reassigned event3.

    This becomes a problem because my XF86Config-4 file has the CorePointer set to Device "/dev/input/event1". When the device changes X can no longer use the usb touchscreen because the device is now "/dev/input/event3".

    Does anyone know if there is a way to either always assign the same event # to a device, or to set X to use multiple Devices for the same pointer (two "Device" settings in the same pointer will just use the first)? Or maybe I am overlooking something?

    Thanks

    maybe this will help

    http://gentoo-wiki.com/HARDWARE_Synaptics_Touchpad

  3. #3
    pkg
    pkg is offline
    Low Bitrate pkg's Avatar
    Join Date
    Apr 2005
    Location
    Arizona
    Posts
    96
    Unfortunately the link above does not solve my problem but it is great info!

    So I have been thinking of some of the possible ways I could address the problem that I am seeing. Here is the brain-dump:

    - Configure X to use both /dev/input/eventX devices as 2
    ponter devices:
    --- It seems as though X is limited to only allow
    multiple pointers that use the same event interface?
    X locks up when 2 pointers are configured with
    different event interfaces

    - Remove /dev/input/event3 from the system:
    --- No luck so far. After deleting the device from the
    /dev filesystem the touchscreen was still assigned
    event3 on reconnect.

    - Force the touchscreen to only use event1:
    --- Ideal fix. No information found on how to lock a
    USB device to a single event interface.

    So if any of you have any ideas I would love to hear.
    -pkg

    Check out my tC: http://publicjestering.com/tc
    Check out my site: http://publicjestering.com

  4. #4
    Variable Bitrate intuitionsys's Avatar
    Join Date
    Jul 2005
    Location
    Northern Virginia
    Posts
    293
    I have good news for you. There are two ways you can make this work:

    1) edit your /etc/udev/rules.d/ rules files to statically assign the event device to the same event every time. I've had troubles with this but I haven't messed with it alot either.

    2) Create a script that runs when you boot to read /proc/bus/input/devices and get the event number for your touchscreen there, then have the script change your XF86Config file before X starts.

    I am using a Lola RF remote that exhibits the same behaviour. It is annoying too that the driver module gets reset after a hibernation so my software has to take that into account since I'm using a signalling system that reads /dev/input/eventX. I have it set up so the fontend app gets signalled at the end of the "unhibernate" sequence that sets in motion a series of events to reload the module and update its reference to /dev/input/eventX via /proc/bus/input/devices. It works great so far with zero problems (other than a short delay of unresponsiveness to the remote after unhibernation).

    Hope that helps.

  5. #5
    Newbie
    Join Date
    Dec 2004
    Posts
    48
    Quote Originally Posted by intuitionsys
    I have good news for you. There are two ways you can make this work:

    1) edit your /etc/udev/rules.d/ rules files to statically assign the event device to the same event every time. I've had troubles with this but I haven't messed with it alot either.

    2) Create a script that runs when you boot to read /proc/bus/input/devices and get the event number for your touchscreen there, then have the script change your XF86Config file before X starts.

    I am using a Lola RF remote that exhibits the same behaviour. It is annoying too that the driver module gets reset after a hibernation so my software has to take that into account since I'm using a signalling system that reads /dev/input/eventX. I have it set up so the fontend app gets signalled at the end of the "unhibernate" sequence that sets in motion a series of events to reload the module and update its reference to /dev/input/eventX via /proc/bus/input/devices. It works great so far with zero problems (other than a short delay of unresponsiveness to the remote after unhibernation).

    Hope that helps.

    not a bad idea. Get event from proc (grep) then have a script copy over or edit a line in xorg.conf. (might be easier to have multi xorg.conf scripts already edited) then have the script launch X

  6. #6
    pkg
    pkg is offline
    Low Bitrate pkg's Avatar
    Join Date
    Apr 2005
    Location
    Arizona
    Posts
    96
    I was talking to a friend of mine who is quite linux savvy. udev rules are the way to go in this situation. I will post what I find out.

    Since X would need to be restarted each time the touchscreen gets powered on I think this would cause some undesirable interruptions of music/maps/etc. Having a non-X application that can switch event interfaces on the fly would not be too affected by the scripts you mentioned though.

    Thanks for the input. More soon,
    -pkg

    Check out my tC: http://publicjestering.com/tc
    Check out my site: http://publicjestering.com

  7. #7
    pkg
    pkg is offline
    Low Bitrate pkg's Avatar
    Join Date
    Apr 2005
    Location
    Arizona
    Posts
    96
    Quote Originally Posted by DigitalExpl0it
    not a bad idea. Get event from proc (grep) then have a script copy over or edit a line in xorg.conf. (might be easier to have multi xorg.conf scripts already edited) then have the script launch X
    renaming files would be tragically simple in this case.
    -pkg

    Check out my tC: http://publicjestering.com/tc
    Check out my site: http://publicjestering.com

  8. #8
    Newbie
    Join Date
    Dec 2004
    Posts
    48
    Quote Originally Posted by pkg
    renaming files would be tragically simple in this case.
    true but only if X is running.

  9. #9
    pkg
    pkg is offline
    Low Bitrate pkg's Avatar
    Join Date
    Apr 2005
    Location
    Arizona
    Posts
    96
    So I have finally came up with a fix, there were a few things that were all tied up

    I was originally NOT running udev on my system. This was a problem because the behavior of the Linux event interface system is to not constrain a device to a single event device in case the event is in use. So, udev is the solution.

    I installed udev. Incredibly easy on Debian (# apt-get install udev [doesn't get any easier than that!]). I then created a udev rule in the /etc/udev/udev.rules file:

    BUS="usb", KERNEL="event[0-3]*", SYSFS{product}="USB TouchController", SYMLINK="input/touchscreen"

    The rule above creates a symlink from whatever event device file the Linux kernel assigns to the touchscreen to /dev/input/touchscreen.
    "/dev/input/touchscreen" is the device that is used in the XF86Config-4 file for the touchscreen.

    Originally I had left out the KERNEL directive in the rule. This was causing udev to default to the /dev/input/ts0 device for the symlink. This does not work. Adding the KERNEL directive for the event devices fixed this problem and the symlink points to /dev/input/event1 (or event3 depending).

    I was then running into a problem with the pointer not working when the touchscreen would power back on. After doing A LOT of reading I came across the same bug that occurs when the system comes out of hibernation. X loses the pointer!.

    The solution to X losing the pointer was to switch virtual terminals out of X and then back in. ctrl+alt+F1, ctrl+alt+F7. This was not going to work in a keyboard-less system! I then came across a scriptable command "chvt". So, now that I could script the VT change I just needed a way to launch the script when the touchscreen was powered up. This is where hotplug comes in for linux.

    As some of you may know hotplug has the perfect facility for this type of thing (heck, it is what it was made for). So, I added a hotplug "handmap" to the system. I created a new file named touchkitusb in the /etc/hotplug/usb/ directory. This file is a bash script that (essentially) contains the commands: chvt 6; chvt 7. (This script is currently set SUID root though this is not the best way to do it. I will be doing sudo chvt inside of the script instead.)

    So what did this do? When the touchscreen is turned back on udev assigns the /dev/input/hotplug to the correct event# device. Hotplug then detects the device as coming up and executes the touchkitusb script. The system then changes to VT6 and then back to VT7, making the touchscreen work on a power off/power on!

    So what next? There was some mention of a kernel bug in 2.6.9 causing this behavior but I haven't seen any real reference to it yet. I will look into a kernel upgrade at some point. Those of you not using X will probably not have this problem. The udev configuration is mandatory for this situation, the hotplug script is a workaround for the pointer "bug".

    Hope this helps someone
    -pkg

    Check out my tC: http://publicjestering.com/tc
    Check out my site: http://publicjestering.com

  10. #10
    Variable Bitrate intuitionsys's Avatar
    Join Date
    Jul 2005
    Location
    Northern Virginia
    Posts
    293
    Good work! I'd be interested in seeing your final udev rule. I'll be implementing a touchscreen overlay in my system (same driver as yours but just an overlay since my car has an OEM monitor built into the dash already) and this will undoubtedly save me some time getting it working A-OK.

    By the way if anyone uses the ati_remote driver, you need to remove and re-insert the driver after hibernation. I made a hokey workaround for it by having the resume_after_suspend_to_disk script touch a file that my frontend checks for every ten seconds. When the app resumes after hibernation it finds this file and performs the system calls to remove and modprobe the driver and reset the event file it's monitoring.

Page 1 of 2 12 LastLast

Similar Threads

  1. Replies: 15
    Last Post: 05-04-2006, 04:53 PM
  2. Replies: 11
    Last Post: 07-11-2005, 10:28 AM
  3. DC-DC Car Power for Mac Mini
    By MikeH in forum MacCar
    Replies: 53
    Last Post: 02-19-2005, 12:13 PM
  4. USB Power problem please help
    By Uconnputer in forum Power Supplies
    Replies: 9
    Last Post: 12-06-2004, 11:29 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •