[QUOTE=nol_faich;6416329]not able to get multi-desktop, ethernet and wifi working!/QUOTE]
that was some really bad luck.
Hope u filed bugs against them all.
If you can, try Jaunty 9.04 alpha.
Latest kernel 2.6.28-3 works with your driver.
[QUOTE=nol_faich;6416329]not able to get multi-desktop, ethernet and wifi working!/QUOTE]
that was some really bad luck.
Hope u filed bugs against them all.
If you can, try Jaunty 9.04 alpha.
Latest kernel 2.6.28-3 works with your driver.
BUGabundo Linux user #443786
http://BUGabundo.net
I discovered I am lucky enough to have a special chip part of a special wifi device together with a mistake in a configuration file for my wifi LED.
Now the wifi isue is solved and the multi-desktop also (even if i don't understand why).
The next big step will be the restart after having updated my whole system.
My system is now working. I began tests with Ekiga in order to know why the system may freeze.
I still do not have discovered the reason but I can reduce the frequency. I will also write to the libv4l maintainer to see what could be done for the webcam to be usable without the driver having to decode by its own the images.
I'm now happily using your driver on a fresh install of ArchLinux. Install was a breeze I just chose "c" and that was it. Works like a charm, thanks again Nol.
Desktop:Core2Duo E8400 @ 3.0Ghz 2048MB DDR2-800 RAM 512 MB GeForce 9600GT 74 GB SATA WD RAPTOR @ 10K RPM - Hardy Heron 8.04
Laptop:Asus C90s - Intel Core2Duo @2.13 Ghz 2048MB DDR-667 RAM 512MB GeForce 8600 120GB SATA @ 7200 RPM - Hardy Heron 8.04
just to let you guys know it works great with the latest jaunty kernel
$ uname -a
Linux blubug 2.6.28-4-generic #5-Ubuntu SMP Fri Dec 26 22:48:55 UTC 2008 x86_64 GNU/Linux
BUGabundo Linux user #443786
http://BUGabundo.net
@BUGabundo : Thanks for the information. After some modification to be usable with 2.6.25 and 26 and 27, it is pleasant that the driver is OK with 2.6.28.
@Blazercist : Nice to see you again, thanks.
@ all : I will try as soon as possible a modified version of lib4vl2 to make a proof of concept of red-blue channel swap and/or 180° image rotation on the fly. If OK, I will propose that to the libv4l maintainer and the driver will have no more decoding to do with the usual applications. Only Ekiga will still be a problem because of its nasty not 4/3 image format.
Happy newkernelsdriversyear !
Some news about the driver migration to libv4l.
A driver shall not do decode the images, it gets images and that's all because such a CPU consumming task is not suitable for the kernel. This is what I would like to achieve with the future drivers because libv4l is intended for image decoding. Moreover the issues with Ekiga seem to originate the decoding stage, so to put it out the kernel is also good.
The missing tasks to be done by libv4l are :
- swap if necessary the red and blue channels for v4l1 application with color issue
- 180 degree rotation of the image when the webcam informs the driver that the image is upside down because of the rotation of the webcam (or inclination of the screen)
- a third task is the addition of a black padding when the requested size does not respect the width/height ratio.
I wrote to Hans de Goede, the libv4l maintainer.
About the red & blue swap:
Camorama is likely wrong with RGB management because the v4l1's RGB palette has to use colors encoded in the BGR order(the order in BMP images). For quite a very weird, strange, astonish and non-understandable reason, Camorama uses the RGB palette and consider reading colors encoded in the RGB order. As the color error is due to a wrong implementation, libv4l won't correct this. However I thought that Camorama was right with colors, so I will correct this in the existing drivers.
About rotation:
The safer way to manage that may be the addition of a new webcam setting in the v4l2 norm. Libv4l would have to read the setting value on a regular basis to know whether the image has to be rotated or not
About black padding:
I don't know enough of libv4l to actually know what it can do, I'm studying this.
Nothing is actually implemented. Beside that, I made tests with a lightened version of the driver (no image decoding) and this fails with Camorama, Ekiga(v4l2) and aMsn but is OK with Skype and Cheese. I think it is because they do not ask for which palette they accept and refuse the raw webcam data, for aMsn it seems to be because of a truncated -but allowed- implementation of v4l2 not managed by libv4l.
Happy new year also to you, Dr. Nol!
@Soro : Thanks Soro !
@ All :
Some news, I patched libv4l_0.5.7 to manage the rotation of the webcam and I achieve the driver working with Camorama(v4l1), Ekiga (v4l1&2), Skype and Cheese. aMsn still does not get any image, maybe a work around in libv4l is needed for.
I will also add a work around in the driver to allow to swap blue and red channels.
Once done and the patch accepted, the driver with no more decoding will be released.
After that, I will make a test version with the hope to identify automagically when a webcam is 1,3MP or 2MP (Only the "ms" and "sim" user are concerned by these tests).
FYI gl860+libv4lc is working great with latest kernel
$ uname -a
Linux blubug 2.6.28-5-generic #15-Ubuntu SMP Fri Jan 23 01:16:33 UTC 2009 x86_64 GNU/Linux
UPDATE
gl860_gl860_libv4lc will stop responding if I test the webcam with v4l, but works great with v4l2
Last edited by BUGabundo; January 24th, 2009 at 10:45 AM.
BUGabundo Linux user #443786
http://BUGabundo.net
Bookmarks