Mimo 720-S Touchscreen [Solved]

[philharlow]

I just tried erazor's kernel and I finally see my screen show up as an input! Thanks erazor! I still see the error -71 too so I assume I'm now where you guys are.

This is the relevant dmesg output:

Code: Select all

hub 1-1.3.4:1.0: state 7 ports 4 chg 000c evt 0000
hub 1-1.3.4:1.0: port 2, status 0101, change 0000, 12 Mb/s
hub 1-1.3.4:1.0: port 2 not reset yet, waiting 10ms
usb 1-1.3.4.2: new high-speed USB device number 8 using dwc_otg
hub 1-1.3.4:1.0: port 2 not reset yet, waiting 10ms
usb 1-1.3.4.2: skipped 1 descriptor after interface
usb 1-1.3.4.2: skipped 1 descriptor after interface
usb 1-1.3.4.2: default language 0x0409
usb 1-1.3.4.2: udev 8, busnum 1, minor = 7
usb 1-1.3.4.2: New USB device found, idVendor=17e9, idProduct=401a
usb 1-1.3.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.3.4.2: Product: mimo
usb 1-1.3.4.2: Manufacturer: DisplayLink
usb 1-1.3.4.2: SerialNumber: 7094319
usb 1-1.3.4.2: usb_probe_device
usb 1-1.3.4.2: configuration #1 chosen from 1 choice
usb 1-1.3.4.2: adding 1-1.3.4.2:1.0 (config #1, interface 0)
usb 1-1.3.4.2: adding 1-1.3.4.2:1.1 (config #1, interface 1)
hub 1-1.3.4:1.0: port 3, status 0101, change 0000, 12 Mb/s
hub 1-1.3.4:1.0: port 3 not reset yet, waiting 10ms
usb 1-1.3.4.3: new full-speed USB device number 9 using dwc_otg
usb 1-1.3.4.3: device descriptor read/64, error -71
usb 1-1.3.4.3: device descriptor read/64, error -71
usb 1-1.3.4.3: new full-speed USB device number 10 using dwc_otg
hub 1-1.3.4:1.0: port 3 not reset yet, waiting 10ms
usb 1-1.3.4.3: device descriptor read/64, error -71
usb 1-1.3.4.3: device descriptor read/64, error -71
usb 1-1.3.4.3: new full-speed USB device number 11 using dwc_otg
usb 1-1.3.4.3: device not accepting address 11, error -71
hub 1-1.3.4:1.0: port 3 not reset yet, waiting 10ms
usb 1-1.3.4.3: new full-speed USB device number 12 using dwc_otg
usb 1-1.3.4.3: device not accepting address 12, error -71
hub 1-1.3.4:1.0: unable to enumerate USB device on port 3
hub 1-1.3.4:1.0: state 7 ports 4 chg 0000 evt 0008
usbtouchscreen 1-1.3.4.2:1.0: usb_probe_interface
usbtouchscreen 1-1.3.4.2:1.0: usb_probe_interface - got id
input: DisplayLink mimo as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.4/1-1.3.4.2/1-1.3.4.2:1.0/input/input0
usbtouchscreen 1-1.3.4.2:1.1: usb_probe_interface
usbtouchscreen 1-1.3.4.2:1.1: usb_probe_interface - got id
input: DisplayLink mimo as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.4/1-1.3.4.2/1-1.3.4.2:1.1/input/input1
usbcore: registered new interface driver usbtouchscreen
usbhid 1-1.3.1.3:1.0: usb_probe_interface
usbhid 1-1.3.1.3:1.0: usb_probe_interface - got id
input: Logitech USB Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1.3/1-1.3.1.3:1.0/input/input2
hid-generic 0003:046D:C52E.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-bcm2708_usb-1.3.1.3/input0
usbhid 1-1.3.1.3:1.1: usb_probe_interface
usbhid 1-1.3.1.3:1.1: usb_probe_interface - got id
input: Logitech USB Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1.3/1-1.3.1.3:1.1/input/input3
usbhid 1-1.3.1.3:1.1: looking for a minor, starting at 0
hid-generic 0003:046D:C52E.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-bcm2708_usb-1.3.1.3/input1
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver udlfb
EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
bcm2835 ALSA card created!

[erazor]

Well, did you use the udev rule and the shell script? This fixed the usb-errors for me.

Anyway, I tried different things yesterday and for me it seems that the input device does not get any event.

I tried xev and evtest - no events at all.

I also tried the evdev-debug kernel module and set kernel verbosity to 8 - still nothing.

[jwilker2]

Hello,
Do any of you see both of these devices when you run $lsusb?
Bus 001 Device 004: ID 17e9:401a DisplayLink <<-- This obviously is fb0 the monitor
Bus 001 Device 005: ID 1ac7:0001 <<-- Less obviously the touchsceen

I have the udev rule and shell script in place on the Rpi and all I see is:
Bus 001 Device 006: ID 17e9:401a DisplayLink

Our latest thought is the error -71, device failed to accept address or whatever is Rpi failing to latch this ID 1ac7:0001 device.

[JakeWisniewski]

As I stated before, I am testing two touchscreens and this is my lsusb output which I believe confirms jwilkers thoughts about the error -71

Code: Select all

pi@raspberrypi ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 008: ID 17e9:401a DisplayLink
Bus 001 Device 013: ID 17e9:0211 DisplayLink
Bus 001 Device 014: ID 04e7:0050 Elo TouchSystems 2216 AccuTouch® Touchmonitor Interface
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 05e3:0612 Genesys Logic, Inc.
Bus 001 Device 006: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 007: ID 0409:005a NEC Corp. HighSpeed Hub

You can see the two displaylink devices for the monitors and then the Elo TouchSystems for the touch portion of the working touchscreen. I'm curious if anyone knows how to find out which driver the Elo is using? I am working off of jwilkers kernel which he compiled with the drivers included and not as modules so lsmod doesn't return anything useful.

Erazor, Do you think you can try to add the vendor/product ID (1ac7:0001) to the e2i driver since that is apparently the correct driver according to one of Dane's posts from a few pages back?

Code: Select all

usb 1-1.2.2.3: new full-speed USB device number 8 using dwc_otg
usb 1-1.2.2.3: New USB device found, idVendor=1ac7, idProduct=0001
usb 1-1.2.2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.2.2.3: Product: USB Touchpanel
usb 1-1.2.2.3: Manufacturer: e2i Technology, Inc.
usb 1-1.2.2.3: SerialNumber: L000000000
input: e2i Technology, Inc. USB Touchpanel as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2.3/1-1.2.2.3:1.0/input/input0

I would try it myself if I had any clue how.

[jwilker2]

Hello,
I recently found these two issues posted on github:

Alex thanks for posting this.
https://github.com/raspberrypi/linux/issues/224

Add udlfb for displaylink screens.
https://github.com/raspberrypi/firmware/issues/141
Perhaps we should all go over there and pile on.

[jwilker2]

Hello Jake,

I believe Erazor's already touched on it: see where he recommended we patch the source code to add the monitor?

Code: Select all

    diff --git a/drivers/input/touchscreen/usbtouchscreen.c b/drivers/input/touchscreen/usbtouchscreen.c
    index 721fdb3..726e985 100644
    --- a/drivers/input/touchscreen/usbtouchscreen.c
    +++ b/drivers/input/touchscreen/usbtouchscreen.c
    @@ -222,6 +222,7 @@ static const struct usb_device_id usbtouch_devices[] = {
     
     #ifdef CONFIG_TOUCHSCREEN_USB_E2I
            {USB_DEVICE(0x1ac7, 0x0001), .driver_info = DEVTYPE_E2I},
    +       {USB_DEVICE(0x17e9, 0x401a), .driver_info = DEVTYPE_E2I},
     #endif
     
     #ifdef CONFIG_TOUCHSCREEN_USB_ZYTRONIC

He's way out in front of us on this. This fix is in the kernel you've got as well as the one he supplied.

[JakeWisniewski]

Thanks J.

I knew he did it before but I didn't see that it was for the E2I driver. Oh well, here's hoping the issue threads will spark something from the creators/developers end.

[philharlow]

So I put the udev rule in place tonight but I still get the error -71. Can you tell if I just entered the rule incorrectly or am I having separate issues from you guys?

my dmesg

Code: Select all

hub 1-1.3.4:1.0: state 7 ports 4 chg 000c evt 0000
hub 1-1.3.4:1.0: port 2, status 0101, change 0000, 12 Mb/s
hub 1-1.3.4:1.0: port 2 not reset yet, waiting 10ms
usb 1-1.3.4.2: new high-speed USB device number 8 using dwc_otg
hub 1-1.3.4:1.0: port 2 not reset yet, waiting 10ms
usb 1-1.3.4.2: skipped 1 descriptor after interface
usb 1-1.3.4.2: skipped 1 descriptor after interface
usb 1-1.3.4.2: default language 0x0409
usb 1-1.3.4.2: udev 8, busnum 1, minor = 7
usb 1-1.3.4.2: New USB device found, idVendor=17e9, idProduct=401a
usb 1-1.3.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.3.4.2: Product: mimo
usb 1-1.3.4.2: Manufacturer: DisplayLink
usb 1-1.3.4.2: SerialNumber: 7094319
usb 1-1.3.4.2: usb_probe_device
usb 1-1.3.4.2: configuration #1 chosen from 1 choice
usb 1-1.3.4.2: adding 1-1.3.4.2:1.0 (config #1, interface 0)
usb 1-1.3.4.2: adding 1-1.3.4.2:1.1 (config #1, interface 1)
hub 1-1.3.4:1.0: port 3, status 0101, change 0000, 12 Mb/s
hub 1-1.3.4:1.0: port 3 not reset yet, waiting 10ms
usb 1-1.3.4.3: new full-speed USB device number 9 using dwc_otg
usb 1-1.3.4.3: device descriptor read/64, error -71
usb 1-1.3.4.3: device descriptor read/64, error -71
usb 1-1.3.4.3: new full-speed USB device number 10 using dwc_otg
hub 1-1.3.4:1.0: port 3 not reset yet, waiting 10ms
usb 1-1.3.4.3: device descriptor read/64, error -71
usb 1-1.3.4.3: device descriptor read/64, error -71
usb 1-1.3.4.3: new full-speed USB device number 11 using dwc_otg
usb 1-1.3.4.3: device not accepting address 11, error -71
hub 1-1.3.4:1.0: port 3 not reset yet, waiting 10ms
usb 1-1.3.4.3: new full-speed USB device number 12 using dwc_otg
usb 1-1.3.4.3: device not accepting address 12, error -71
hub 1-1.3.4:1.0: unable to enumerate USB device on port 3
hub 1-1.3.4:1.0: state 7 ports 4 chg 0000 evt 0008
usbtouchscreen 1-1.3.4.2:1.0: usb_probe_interface
usbtouchscreen 1-1.3.4.2:1.0: usb_probe_interface - got id
input: DisplayLink mimo as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.4/1-1.3.4.2/1-1.3.4.2:1.0/input/input0
usbtouchscreen 1-1.3.4.2:1.1: usb_probe_interface
usbtouchscreen 1-1.3.4.2:1.1: usb_probe_interface - got id
input: DisplayLink mimo as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.4/1-1.3.4.2/1-1.3.4.2:1.1/input/input1
usbcore: registered new interface driver usbtouchscreen
usbhid 1-1.3.1.3:1.0: usb_probe_interface
usbhid 1-1.3.1.3:1.0: usb_probe_interface - got id
input: Logitech USB Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1.3/1-1.3.1.3:1.0/input/input2
hid-generic 0003:046D:C52E.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-bcm2708_usb-1.3.1.3/input0
usbhid 1-1.3.1.3:1.1: usb_probe_interface
usbhid 1-1.3.1.3:1.1: usb_probe_interface - got id
input: Logitech USB Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1.3/1-1.3.1.3:1.1/input/input3
usbhid 1-1.3.1.3:1.1: looking for a minor, starting at 0
hid-generic 0003:046D:C52E.0002: input,hiddev0,hidraw1: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-bcm2708_usb-1.3.1.3/input1
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver udlfb
EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
bcm2835 ALSA card created!

[jwilker2]

Hello Phil,

I noticed you visited github and endorsed adding udlfb to the native kernel for displaylink screens. That's great, if they listen to us then we'll be able to simply plug in and go that would be so much better for the monitor portion of this exercise.

As far as the error -71's I have no answer for you, however, I've noticed a few things that might help with the confusion these damned things are generating. If you execute '$lsusb' while the monitor is plugged in of course you will note two particular items:

ID 17e9:401a DisplayLink <<-- This is the chip that speaks to the monitor
ID 058f:6254 Alcor Micro Corp. USB Hub <<-- This is a 4 Port Hub on a chip built into the 720S/F
Sadly what you don't currently see:
ID 1ac7:0001 <<--- This is the Holy Grail The Touchscreen device

OK, so where is the damned 1ac7:0001?
(dmesg:)
usb 1-1.3.2.3: device not accepting address 10, error -71 <<--- It's here:
usb 1-1.3.2.3: new full-speed USB device number 11 using dwc_otg
usb 1-1.3.2.3: device not accepting address 11, error -71 <<--- Or here:
hub 1-1.3.2:1.0: unable to enumerate USB device on port 3

WTF? Yup really. These are the devices 'attached' to the Alcor Hub inside the 720 that the driver is trying to read and establish a connection with. Why are there several failures reported when we only want one device? That's because it's a four port hub and the driver is sniffing or sensing each one and returning an error. Is the Alcor chip broken? Nope otherwise it wouldn't work elsewhere. These Alcor chips are like pebbles on a beach, they are everywhere possibly devices like your cellphone and Wii game controller.

Why does this happen? Why does it work on Windows, Ubuntu, Debian, Mac, god only knows what else and not here (currently)? Hmmm, well there are a number of theories with power source issues being the primary one amongst the gurus upstream of us. I'm afraid I disagree, not about whether it's power related rather where and how, but what do I know, right?

Is the Monitor/DisplayLink chip combo slurping up all the power and leaving the driver hanging, could be but these things are generally governed by standards (unless you're MSoft). Is the driver flawed and too sensitive, maybe but likely simply recompiled from an otherwise working system (the linux tried and true method). Could it be electronics and shielding onboard the RPi itself, well yeah it could be.

Will the right combo of wire, wire thickness, powered hub, wall wart etc. fix it? I flatly do not know nor do I have the expertise to even render an opinion.

[jwilker2]

So I put the udev rule in place tonight but I still get the error -71. Can you tell if I just entered the rule incorrectly or am I having separate issues from you guys?

I'm sorry Phil in the midst of my hopefully helpful rant I didn't answer your question .

No, you are not having separate issues from us, as far as I know we all get error -71s. erazor indicated he was using a bench top power supply but I never figured out whether he had made the errors go away.

If he succeeded I'd find that cheery news, it would put a little better light on a thus far intractable problem. At least it would satisfy some of my curiosity.

[JakeWisniewski]

Here's something I found after reading your "rant" J. Seems like it could be part of the problem.

http://himeshp.blogspot.com/2012/07/ras ... imate.html

I'll have to see if my boss doesn't mind ordering another Pi once I screw up my current one.

[jwilker2]

Wow, now that's what I'm talkin' about Jake...

Time to fire up the old soldering iron and burn some stuff up , hell it might even work. I killed two RPis on Saturday or Sunday, why should I have all the fun?

Might I suggest an RPi Model A? $25 dollars U.S.D. and you could dig a smaller grave since it lacks a bulky network adapter (which incidentally draws plenty of power on it's own).

Seriously, you might have found a solution.

I discovered, it was right out in the open but I hadn't noticed, that one of the other forum members DaneGardner and his working Mimo Touchscreen is based on a different model than ours. I suspected as much and read his communications with Phil carefully and sure enough his lacks the Alcor Hub chip which was the subject of my 'rant'. This touchscreen monitor might and probably does work just great. Mimo Model 720-F is not as cool as the 720-S ha ha as in no stand no rotation etc.

Phil and I ran into a fellow named George Galt on Github who is working on bringing a Mimo Model 720-F up under ArchLinux for the RPi. He's had it running successfully in the past but neglected it he says and now he's reinstalling it, he set up a forum for us to monitor his progress @ https://github.com/ggalt/RaspberryArch/issues/1. If you've not tried ArchLinux on the RPi it's stupid fast but as friendly as a rock. I love it but I'm lazy and Raspbian has all the bells and whistles and is fast too.

[JakeWisniewski]

So I posted that hack last night when my Pi was still at work. I just got to work and took a look at my Pi to find out there are no fuses were the picture is showing. All I have is a hole for a case.

It looks as if C32 was moved to were F1 fuse was and F2 fuse is nowhere to be found. So much for that.

I'll have to take a look at Arch to see if there is anything I can find. I've been doing most of my dev on raspbian so a new flavor for my eyes might be good..

[jwilker2]

So I posted that hack last night when my Pi was still at work. I just got to work and took a look at my Pi to find out there are no fuses were the picture is showing. All I have is a hole for a case.
It looks as if C32 was moved to were F1 fuse was and F2 fuse is nowhere to be found. So much for that.
I'll have to take a look at Arch to see if there is anything I can find. I've been doing most of my dev on raspbian so a new flavor for my eyes might be good..

I've got two original RPis that fit the profile for this hack, however, wow it's deceptively tight in there. Gotta have good hands to get in and out of there. Have a video microscope but I'm not sure I'm man enough for this one.

Arch is good stuff, particularly for custom code because it for the most part does only what you want and only when you want it. Since it's not bloated with features, tools and processes unneeded by your custom app or configuration it moves right along. It's far less likely to self destruct after downloading an extraneous update for something you don't need, want or never use.

Want a headless server based on the Pi? Then Arch is the stuff. If you want wireless or a minimal desktop that's cool but you gotta install it. Need to stream video and sensors from a remote location then you'd be foolish not to use Arch because it CAN keep up and you won't wear your Pi and disk(s) out with unwanted I/O.

[JakeWisniewski]

Two original Pi's as in Rev. 1? If that's the case I find his pictures interesting because it has those fuses but also has network which I thought was only added on Rev. 2.

Am I taking crazy pills or am I just misinformed?

[jwilker2]

Jake & Phil

See the feedback below provided by George Galt. He provided me with the opportunity to watch him rebuild his touchscreen from bare metal. I now know for sure that the Mimo 720-F works:
Bus 001 Device 005: ID 17e9:0335 DisplayLink
Bus 001 Device 006: ID 1ac7:0001

Mine: Mimo 720-S does not (probably as Jake revealed because of the Pi's onboard fusing)
Bus 002 Device 003: ID 058f:6254 Alcor Micro Corp. USB Hub <<--- Not in 720-F
Bus 002 Device 004: ID 17e9:401a DisplayLink

Code: Select all

Jim:

Some good news. At some point over night, the little Pi finished building its kernel (sorry, I had the version wrong, it's 3.6.11-6-ARCH+). On reboot, the Mimo 720f showed a green screen. Unfortunately, I couldn't get X to start in the 5 minutes I had before going to work, but it looks like the touchscreen is recognized. Here is what dmesg shows:

[    4.151664] usb 1-1.2.3: Product: USB Touchpanel
[   15.919912] input: e2i Technology, Inc. USB Touchpanel as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0/input/input3
[   15.933642] usbcore: registered new interface driver usbtouchscreen

And lsmod shows:

Module                  Size  Used by
udlfb                  16884  0
usbtouchscreen         12130  0
evdev                   9370  0

I will see if I can delve into why X didn't start remotely over lunch, but I probably won't have much more to report until I can get home tonight. At least this looks like a good start.

I'm not sure what you might need at this point, but I would suggest that you try rebuilding your kernel using the directions here: http://anup.info/blog/2012/10/13/raspberry-pi-mimo-monitor and here: http://www.pur3.co.uk/view.php?DisplayLink (which talks about how to enable the touchscreen for the Mimo 740, which is the driver I used).

Good luck,

George

[jwilker2]

Two original Pi's as in Rev. 1? If that's the case I find his pictures interesting because it has those fuses but also has network which I thought was only added on Rev. 2.

Am I taking crazy pills or am I just misinformed?

It's a bit like the Star Wars Sexology (he he he) where 4,5,6 preceded 1,2,3

Model B - released first has integrated ethernet:
Rev 1. <<-- No screw holes two fuses
Rev 2. <<-- Screw holes 1 Fuse

Model A - just released no ethernet port
Rev. 2 <<-- Screw holes and 1 fuse probably

[JakeWisniewski]

Oh ok. That makes sense now. Well, in our efforts to figure stuff out about the Pi I decided to go the opposite direction for a change and tore apart the mimo.

Here it is in all its glory. I've highlighted the alcor chip with a red box.

Bigger picture here http://i49.tinypic.com/2q3dtvd.jpg

Also the chip itself is an Alcor AU6254. Here is a link to the datasheet for any of you electrical engineers that can figure out which pins we need to short. http://www.datasheet4u.net/datasheet/A/ ... r.pdf.html

[ggalt]

All:

For those willing to switch to ArchLinux, the maintainer of the Raspberry Pi kernel there has kindly included the displaylink framebuffer and touchscreen drivers (for the 720F series) in the latest kernel. I have installed the new kernel and can report that I get both X working and the touchscreen. I've got my xorg config file here: https://github.com/ggalt/RaspberryArch. I initially had trouble with a reversed Y axis, but discovered that I was referencing the wrong device in /dev/input/event. All is working now.

Good luck,

George

[jwilker2]

All:

For those willing to switch to ArchLinux, the maintainer of the Raspberry Pi kernel there has kindly included the displaylink framebuffer and touchscreen drivers (for the 720F series) in the latest kernel. I have installed the new kernel and can report that I get both X working and the touchscreen. I've got my xorg config file here: https://github.com/ggalt/RaspberryArch. I initially had trouble with a reversed Y axis, but discovered that I was referencing the wrong device in /dev/input/event. All is working now.

Good luck,

George

Fantastic!
I've reversed the entries before too with some bizarre results.

Thanks for the code.

Jim

[jwilker2]

Phil & Jake,

GOOD NEWS!

Make the following modification to /boot/cmdline.txt from this:

Code: Select all

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

To this:

Code: Select all

dwc_otg.lpm_enable=0 dwc_otg.speed=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

REBOOT and enjoy your touchscreens!
(Jake, please put the monitor back together )

You should see this:
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 17e9:401a DisplayLink
Bus 001 Device 008: ID 1ac7:0001 <<<---- Look Touchscreen Happiness
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 050d:0237 Belkin Components F5U237 USB 2.0 7-Port Hub
Bus 001 Device 005: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 001 Device 006: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

and no more Error -71s in dmesg.

[JakeWisniewski]

JWilker, you are the man. How the hell did you figure that one out?

I see the touchscreen but won't be able to get all touchy feely with it until monday. The awful part about this is I really think I found this a few weeks ago when i was looking into the dwc_otg errors that we were getting and completely overlooked it since another forum basically dismissed it as a powered hub issue.

Either way, nice work on the find and thanks to everyone involved.

[philharlow]

Holy moly. JWilker, you just made my month! I tried out your "dwc_otg.speed=1" change and VIOLA! I get ZERO error -71s and x11 IMMEDIATELY reacts to touch input! I can also use any usb cable, thick, thin, single or dual powered, and they all work great! Now all I need to do is calibrate the screen, which I'm going to try now by following the steps provided by Dane earlier in the thread. Right now I'm using the kernels and modules you provided, but in the next week or two I'd like to walk back our efforts into the simplest/easiest to follow steps to get the 720-S running smoothly for others who come later.

I am so jazzed the screen works! I owe you guys a ton! Thank you!

UPDATE:

Although the touchscreen worked perfectly, I could not get the display to work on startup with wheezy + erazor's kernel, modules, and udev rule. I tried a fresh copy of wheezy with DaneGardner's displaylink kernel, jwilker's modified cmdline.txt, and tada! The screen works!
I've included my working xorg.conf for anyone who needs it, using DaneGardner's post for getting the calibration values and using the command sudo evtest /dev/input/by-id/usb-e2i_Technology__Inc._USB_Touchpanel_L000000000-event-if00.
I then disabled the screen timeout by editing /etc/lightdm/lightdm.conf and un-commenting the line under "[SeatDefaults]" that reads "#xserver-command=X" and adding " -s 0 -dpms" so you have "xserver-command=X -s 0 -dpms" and then rebooting.
Next I cut off a male hdmi adapter and plugged it in so it would boot without a display and bam, my project is one power cable running to the hub, which powers the pi and the display, and one usb cable running to the screen! It's pretty slick, all on 5v, now it's ready for a UI!

my xorg.conf

Code: Select all

Section "Device" 
  Identifier "uga" 
  driver "fbdev" 
  Option "fbdev" "/dev/fb1" 
  Option "ShadowFB" "off"
EndSection 

Section "Monitor" 
  Identifier "monitor" 
EndSection 

Section "Screen" 
  Identifier "screen" 
  Device "uga" 
  Monitor "monitor" 
EndSection 

Section "ServerLayout" 
  Identifier "default" 
  Screen 0 "screen" 0 0
  InputDevice   "touchscreen" "CorePointer"
  Option     "Xinerama" "Off"
EndSection

Section "InputDevice"
  Identifier "touchscreen"
  Driver "evdev"
  Option "Device" "/dev/input/by-id/usb-e2i_Technology__Inc._USB_Touchpanel_L000000000-event-if00"
  Option "DeviceName" "touchscreen"
  Option "ReportingMode" "Raw"
  Option "SendCoreEvents" "On"
  Option "Calibrate" "1"
  Option "Calibration" "630 32000 1100 31800"
  Option "InvertY" "true"
  Option "InvertX" "true"
  Option "SwapAxes" "false"
EndSection

[jwilker2]

Hello Phil,

I'm really glad to hear you got moving again. Figuring that out was a bit of a struggle and that is to say the least. Particularly when being repeatedly misinformed, the RPi being what it is which is awesome has quirks. The USB dwc_otg adapter may be chief among them but is being utilized in ways unimagined by it's integrators.

Anyway the "dwc_otg.speed=1" cmdline.txt hack as it were is a mod that slows down the USB bus from a theoretical 480Mbs to a seemingly pedestrian 12Mbs which allows the touchscreen to catch up. It was all I could think of to do and worked immediately. The 'mod' is unnoticeable for most peripherals: keyboards, mice, printers and touchscreens but if you have a device such as a wireless network dongle or SSD connected you could "feel the pain".

If you google "dwc_otg.speed=1" you'll see a bunch of folks using it to ameliorate a number of issues. Half a dozen people or so dismissed the Error -71 as power related, bad wire, bad kharma, voted for Obama or you ain't holding your mouth right. What it appears to mean is 'undefined or unconfigurable device issue on dwc_otg adapter' or in other words 'timing'. Other Mimo Monitors and their cousins lack the Alcor hub which when powered likely needs time to configure itself and the lag causes the driver to glitch.

By the way, your calibration appears spot on! Saved me having to figure it out.

As it turns out my 'touchscreen' kinda hates me. It's frustratingly insensitive which is probably due it's age but with the use of a stylus it works well and the pointer tracks right along. Or I might end up shooting it in the face which is how we fix stuff in Alabama.

[erazor]

Code: Select all

dwc_otg.speed=1

also worked for me.

But I had to reload the modules like this:

Code: Select all

rmmod udlfb
rmmod usbtouchscreen

modprobe udlfb
modprobe usbtouchscreen