Open ggalt opened 11 years ago
Jim:
Here is the output from lsusb related to the Mimo: Bus 001 Device 005: ID 17e9:0335 DisplayLink Bus 001 Device 006: ID 1ac7:0001
I believe that the unlisted device is the touchscreen. As to your suggestion that I keep my old kernel tree, it seems to no longer work (I attempted to reinstall it, but got no change). I'm currently rebuilding the kernel to see if the change in the firmware can be addressed with a new build.
FYI, I only did 2 changes to my kernel configuration, adding support for udlfb and enabling USB touchscreens, which included a touchscreen listed by the kernel configuration as the "Mimo 740". I'll let you know what I find.
George
George:
If you can see those devices with a simple lsusb, then I believe you are in great shape. We have a problen in that 'our' Mimo Monitor contains an Alcor USB Hub chip and RPi seemingly hates it.
Another word of unsolicited advice: when you build your kernels(s) try select [*] rather than [m], just what we're asking popcornmix to do. Coupled with the earlier kernel hack I recommended you'll be able to update your 'external' firmware without killing your custom kernel and it'll be much more portable.
Look forward to seeing how you get on.
Just curiosity but your profile says you live in D.C., whereabouts?
I grew up about twenty miles east of D.C. in Anne Arundel County and got my mind expanded as it were at Maryland in College Park.
Bethesda, though I lived in the Logan Circle area of DC for about 20 years before that, so I consider myself almost a native.
On the kernel hack you mentioned, if you mean:
This from another forum that should help you prevent finding your 'baby' DOA: 'If your goal is to achieve something experimental, are happy to compile your own kernel, and are frustrated by updates breaking it, the solution is to do updates this way: sudo SKIP_KERNEL=1 rpi-update (updates your firmware) git pull (from your kernel source directory) Compile and install as normal.
I unfortunately started the compile prior to your comment, but I'm also not sure how to convert it from Raspian to Arch terminology. If my new kernel doesn't do the trick, I'll see what I can do about it.
FYI, I'm compiling on the Pi, so it will probably not be done until late tonight.
George
Compiling on the Pi wow your a patient man :)
Yeah, I lived on 19th between K & L but that got old in a hurry was cool livin the urban lifestyle for a while.
The kernel.img of course is independent of the Distro. So the setup ought to be the same I think. You've used rpi-update before yes? It sucks down the latest officially released kernel and firmware. Setting the parameter says 'yeah get the firmware' and hands off the kernel.
Jeez, it just occurred to me, you don't commute up and down 355 everyday do you?
I worked at the Naval Research Laboratory and Goddard which damned near caused me to lose my mind or did. Now if I see three cars sitting at a traffic light I make an immediate u-turn. I can't even imagine driving across Montgomery County at rush hour without developing a twitch.
Jim
No I bike down MacArthur Blvd and the Capital Crescent trail. If I see more than 2 blue herons I turn around and go home! ;-)
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
Nice!
Looks like you are in business... I never cease to be amazed at what these little guys can do.
As far as our (720-S owners) predicament is concerned it looks like it boils down to a basic hardware incompatibility. The 720-S has an integrated Alcor 4 Port Hub IC that exceeds the power limits imposed by fusing onboard the Pi. This causes the touchscreen component to be left essentially disabled at boot which likely means we are SOL. For fun, take a look at this link http://himeshp.blogspot.com/2012/07/raspberry-pi-usb-power-issues-ultimate.html this guy is forcing the fuse tolerance higher. I'm not even sure this would increase it enough for us to squeeze in. The hack here requires 700 degree brain surgery with little assurance of success and the area on the Pi is urrr-uh really small.
George, thanks for investing the time because it's been useful to me. I've got confirmation of my suspicions that this problem was related to this model only and that is more than we as a group could confirm before.
Thanks again.
Regards,
Jim
Jim:
I'd suggest the powered hub route. I actually use a Rosewill powered hub to power both the RaspberryPi and the Mimo screen (thereby reducing my costs for purchasing a separate Pi power supply). The wiring looks a little screwy because you end up connecting to the hub both from the USB port (as the upstream parent of the hub) and from the power side to draw power. I then connect both connections from the Mimo's Y-shaped USB cable to the hub so that it gets the power it needs (from the hub) and the signal it needs from the Pi (through the hub). It also avoids power feeding back into the Pi from the Mimo's Y-cable, which you get if you connect it directly.
On another note, if you don't mind switching distros, the guy building the ArmArch distro is updating the kernel with the displaylink framebuffer driver and the usb touchscreen driver. You can see his post here: http://archlinuxarm.org/forum/viewtopic.php?f=31&t=5175&p=29171#p29170.
George
The news on the updated or displaylink integrated ArmArch is great! I'll definitely be a customer for that. I'm an Arch fan anyway.
The wiring confuses me a bit. Could you throw in a picture maybe? All the stuff I do is with a powered hub attached because I have them and I use SSD disks, wireless, bluetooth and whatever else on and off. I'm intersted to see if you've a loop or something in there I hadn't imagined.
Stay in touch, what you're up to fits nicely with my various adventures.
I'll pass along that ArchArm is integrating DisplayLink, that should make a few people happy. I was telling a guy on another forum why I think Arch rocks for custom code, custom configs and speed this morning.
Thanks
I'll see what I can do about a picture, but I'm not sure you really need it. Think of it this way, normally, one would connect the USB header of the Pi to a hub to plug in more than 2 items, which is what I do. Touchscreen, keyboard, etc. are all attached to the hub. However, since the hub is powered, I have the Pi's power cable (which would normally be attached to a USB wall wart) draw power from the hub instead.
Duh OK I'm back... I see, I'm sorry my mind was someplace else but that's simple enough and I'll give it a try.
You read my mind and posted a compiler config for ArchArm already, I was going to ask you for a copy.
Have you ever used fbcon before? If not look at the first 4 or 5 paragraphs here: http://www.mjmwired.net/kernel/Documentation/fb/fbcon.txt . Pis lack that frontend that's so critical to some and potentially useful for non graphics and basic applications. In all my years of twiddling with Unix/Linux I've never tried it. So I was thinking I might give it a shot.
Thanks for the suggestion.
Jim:
A few updates. I got home and twiddled with the xorg config and a few other things. The DisplayLink framebuffer package I used from AUR puts the drivers in the wrong directory (it should be /usr/lib/xorg/modules/drivers/ but they get put in /usr/local/lib/xorg/modules/drivers/, and easy fix with a symbolic link). I now have a working X AND I have a working usb Touchscreen. Unfortunately, the Y axis is inverted, and I haven't been able to fix that yet. I'll load my config so you can take a look and see if you have any suggestions.
BTW, if you are going to go the Arch route, you will need to add the following packages from AUR (and you will need to set up your system to build AUR packages): https://aur.archlinux.org/packages/libdlo/ https://aur.archlinux.org/packages/xf86-video-fbdev-for-displaylink/
BTW, I haven't had a chance to try updating to the new kernel and am still using my custom kernel. I'll try that later and see what happens (on a different SD, of course!!).
George
Jim:
I've loaded the new stock Arm Arch kernel and it works for both the udlfb and touchscreen drivers!! No more 18 hour kernel compiles for me!! The Y-axis of the touchscreen is still reversed, so I'll start working on that soon. I'm going to be tied up for the next week on another project, so I probably won't come back to this until at least the next week.
If you convert to Arch and solve the Y-axis issue, please let me know.
Thanks,
George
George,
I'll be setting up Arch for certain at this point, however, I'm dealing with a desk based mountain of solder, soldering irons, flux, jumpers, springs, relays, and plates I can barely reach my keyboard. Worse than that my wife's gonna make me come home and mow the lawn.
When you get a minute, post your xorg.conf for me if you would. Is it the touchscreen that's tracking in reverse or is the screen inverted?
I'll gladly look at it.
Allowing those who want to take the discussion off of RaspberryPi/Firmware issues board to have a clear place to discuss as per JWilker2's suggestion in https://github.com/raspberrypi/firmware/issues/141#issuecomment-14573792