I want to install the drivers of the video camera on my linux computer.
I write the command:
modprobe usbserial vendor=... product=...
what I expected to get was ttyUSB0 (or sth simmilar) in the /dev directory.
Instead what is getting installed is sg3 (whatever that is) and when I run a program that is supposed to send a command to start recording I get no results (but no errors either).
(I changed what I had previously: fd = open(/dev/ttyUSB0,...) to /dev/sg3 but I guess this is not a configuration that enables sending this kind of data.
What might be the problem? (Sorry if it's a basic question)
cameras and linux can be tricky.
Start by plugging in the camera and running
lsusb
google for the id to see if anyone has a step by step tutorial or at very least can tell you which modules are needed.
Most common drivers seem to have been migrated to the kernel, so rebulid your kernel make sure the modules are built.
Some more obscure usb modules have to be built by hand.
Related
I created a simple module that controls wheter a USB supplies power for a device when in host mode or not. When loaded, this module cuts off the power to any device connected until told otherwise.
It is also desired that when booted, the system comes with both my module loaded, and the USB supply cut off. To this end, so far I've tried:
Setting my module as a kernel built-in: had no effect, modules that are loaded later overrun my configuration;
Creating an init.d script: Created the script, and set it up to run on rc5. No luck as well, I run into multiple problems with USB devices (such as usb 2-1: device descriptor read/64, error -110);
I'm running Kernel 3.12 on a custom board, and I've tested that the module works as intended if I load it manually (via modprobe) into the system, after logging in.
Ideally, I want to keep these configurations to be done during boot, without any need of logins and such.
So, my question is: how can I postpone the module loading until the last possible minute, assuring that any other configuration is already finished? Also, is udev a good solution for this sort of thing? From what I read, I had the impression it wouldn't be the best fit...
Regards,
Guilherme
So, I've figured out how to get rid of the errors when using an init.d script. All that is needed is to unbind the devices before loading the module. the following line before the modprobe did the trick for me:
echo "2-1" > /sys/bus/usb/drivers/usb/unbind
Regards,
Guilherme
I am trying to setup a Tegra 3 (Toradex Apalis T30) based system that will have an OpenGL ES based user interface on a touch screen. Unfortunately the standard Linux4Tegra kernel is seriously outdated and the provided graphics driver requires X11 integration. I have found though that I can build the Vanilla Linux kernel and get it running just fine on my board (tested 3.18). I have also found that a DRM Tegra driver is included in the kernel these days and I enabled it in menuconfig and built the kernel using it. I have also managed to get many distros working with the kernel (though I haven't really tried getting X working on any one).
My problem is that beyond this point, I am stuck. I cannot figure out what to do next in order to get GLES rendering up and running with the DRM driver. I have looked around a bit and have seen that Mesa might support GLES via DRM but I am not sure if this will allow me to do so without X? Also, how on earth to I get Mesa configured and compiled for the Tegra DRM driver?
Also, how does one go about configuring the output display using this DRM driver? My target screen is a 24bit parallel RGB display but I have not got that hooked up yet and would like to test with HDMI first. I have literally no idea how one should go about configuring the output display. The only information that I can find that might help involves X and xorg.conf which I will hopefully not be using. My device does output the console correctly on the HDMI display, how does it know to do that? Might this process somehow involve the device tree?
PS. I guess this question is a bit stupid but I am very new to embedded Linux and have just figured out how to build the vanilla kernel etc. and have really no idea of how the Linux display system works beyond just configuring X. Finding information regarding this is also proving hard.
EDIT:
I have gotten XFCE sort of running on HDMI (login does not work and the login windows is very tiny) on Fedora using the OpenTegra driver which in term uses the DRM driver if I am not mistaken so hopefully that is good news?
Nvidia-setting can usually clear things up if you've gotten this far. Typically the video will work if the kernel has been given the correct vesa mode to show the system bootup messages. These are somewhat cryptic but they simple turn into an argument you append to the kernel boot parameters "vga=###".
I recently received a LittleBits Arduino Coding Kit and thought the Arduino IDE would immediately recognize it.
I noticed that when I choose the "Arduino Leonardo" on the Tools -> Board as the instruction video said to do, the Tools -> Serial Port menu is grayed out.
I have already added myself to the "dialout" and "uucp" groups, ran the "arduino" program as root, ran a whole bunch of commands dealing with permissions, restarted the computer, plugged it into all the ports, reinstalled the drivers, and tried everything else I came across. For some reason, I can't figure out how to get this to work.
I use Xubuntu on an i686 architecture by the way, if that even matters.
I think you don't have permissions to read/write the serial port device. Even running Arduino application as root, it's running on a Java JVM, and calls other programs to compile sketches and burn the board... it's hard to figure out what's happening in the background. Also, is not a good idea to run programs as roout unless necessary.
Try this. First list your serial port devices.
ls -l /dev/tty*
There's should be one called /dev/ttyUSB0 or /dev/ttyACM0 or something like that (not /dev/ttySx). That one is your Arduino. Add read/write permissions for every user to that device file.
sudo chmod 666 /dev/ttyUSB0
Use the device you have. Now run the Arduino IDE, if the issue is with permissions, then it's done. Unfortunately, you'll have to do this every time you unplug the board or reboot the system.
I'd like to find a way to make my BeagleBone (white) Rev A6a autologin after being powered up. I'm using Angstrom with kernel 3.2.34, which uses systemd instead of innitab.
I've already seen some topics (like this question) with reference to modifications on some service files (like /etc/systemd/system/getty.target.wants/getty#tty1.service), but that only helped me partly: If I power/reset my BBone while keeping it connected via USB to my computer, it autologs as expected. But, if I just power the BBone with a wallwart (without any other connections), it doesn't seem to log in. At least I believe that's what is happening, as I have a program prepared to autorun after login and it only starts on the first case (with USB on).
I'd appreciate any help. Thanks.
Turned out that a RF module attached to my beaglebone was being powered via USB, and this module should be activated by my test program mentioned in the question. So, when I unplugged my BBone USB cable, I was actually separating its GND from the RF Module's ground.
In short, I just had to use the same source in the entire circuit and keep the autologin configuration explained in the topic I also mentioned in my question.
You could make your program a service and run after user instance of systemd.
Lets say you have a graphical.target in your /usr/lib/systemd/system then just put symlink to ../systemd-user#.target to /usr/lib/systemd/system/graphical.target.wants/system named like systemd-user#<your-user-name>.service.
This systemd-user#.service should containe ExecStart line like /usr/bin/systemd --user.
Then you'll have to add your application's service-file to /usr/lib/systemd/user.
More info is at http://www.freedesktop.org/software/systemd/man/systemd.html and http://www.freedesktop.org/software/systemd/man/systemd.unit.html
I have a serial GPS connected to an embedded PC via serial<->USB adapter (Prolific PL2303). Every 5 minutes a shell script runs a Python script that reads GPS data via Pyserial then upload them to Internet. If I plug my GPS directly to the PC (via PL2303) everything is ok and my system runs forever BUT if I use a usb HUB between pl2303 and the PC I have a this problem: the Python script runs ok for about 3-6 hours then it goes in a D-state (uninterruptible sleep) and the shell script cannot run it again (I can only shutdown the system, no kill possible). I checked my script and I used usb hubs from various vendors (powered and not) with the same result.
PS my embedded pc (from Embeddedarm) runs an updated Debian Lenny.
Ho can I fix it ?
A process in D state means the kernel (most probably a device driver), has put your process into uninterruptible sleep.
To be honest, there is probably quite little you can do about it as a user, unless you intend to debug the kernel USB stack and/or specific USB chipset device driver.
Here is what would do -
Make sure the kernel configuration of you embedded device has the kernel config option for the magic sysreq key and the run time configuration for it turned on. See: http://en.wikipedia.org/wiki/Magic_SysRq_key on how to do that.
Recreate the problem (have the process get stuck in D state).
Find out the PID of the stuck python script with ps and run strace -p PID on it. This will give you the specific system call that the process is sleeping in.
Send the magic sysreq key command 't', that lists all tasks and their kernel stack to console. Look for the specific task of the python script by PID, see at what part of the kernel code exactly are you stuck.
Open the kernel code and try to debug the problem if you can, or port it to the relevant mailing list if you don't.
One more suggestion would be to try and see if the problem goes away in a more recent kernel version then Debian ships. If so, you know it is a bug fixed in newer version of the kernel and you have the choice of either using the newer version and try to port the fix to the old version you care using.
Good luck! you'll need it...
Ubuntu launchpad has a bug filed that is suspiciously like yours. The workaround suggested is:
modprobe -r pl2303
modprobe pl2303
See if this works around the bug?