Please run cheese -v in a terminal and paste the output here

Thanks

I did that and got no output. It runs, I tried clicking on various menus and such. Used it to take a picture (which just grabbed the test bars/static image it displays by default), and then quit but nothing ever printed to the console. If I use the --gst-debug-level=3 option I do get a ton of output, although I'm not sure where to begin to wade through all that. I'm using the 32 bit version of Ubuntu 8.04 BTW.

We're looking in hal for video devices

If you do an lshal do you see output that looks like

udi = '/org/freedesktop/Hal/devices/usb_device_471_311_01680000BE194101_video4linux'
  access_control.file = '/dev/video0'  (string)
  access_control.type = 'video4linux'  (string)
  info.callouts.add = {'hal-acl-tool --add-device'} (string list)
  info.callouts.remove = {'hal-acl-tool --remove-device'} (string list)
  info.capabilities = {'video4linux', 'video4linux.video_capture', 'video4linux.audio', 'access_control'} (string list)
  info.category = 'video4linux'  (string)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_471_311_01680000BE194101'  (string)
  info.product = 'Philips 740 webcam'  (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_471_311_01680000BE194101_video4linux'  (string)
  linux.device_file = '/dev/video0'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'video4linux'  (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/video4linux/video0'  (string)
  video4linux.device = '/dev/video0'  (string)
  video4linux.version = '1'  (string)


Ofcourse your data is different because you have a different camera

Sorry I didn't get back sooner with this. This near as I can tell is the relevant entry:

udi = '/org/freedesktop/Hal/devices/usb_device_5ca_183a_noserial_if0'
  info.bus = 'usb'  (string)
  info.linux.driver = 'r5u870'  (string)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_5ca_183a_noserial'  (string)
  info.product = 'USB Video Interface'  (string)
  info.subsystem = 'usb'  (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_5ca_183a_noserial_if0'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'usb'  (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-8/5-8:1.0'  (string)
  usb.bus_number = 5  (0x5)  (int)
  usb.can_wake_up = false  (bool)
  usb.configuration_value = 1  (0x1)  (int)
  usb.device_class = 239  (0xef)  (int)
  usb.device_protocol = 1  (0x1)  (int)
  usb.device_revision_bcd = 256  (0x100)  (int)
  usb.device_subclass = 2  (0x2)  (int)
  usb.interface.class = 14  (0xe)  (int)
  usb.interface.number = 0  (0x0)  (int)
  usb.interface.protocol = 0  (0x0)  (int)
  usb.interface.subclass = 1  (0x1)  (int)
  usb.is_self_powered = false  (bool)
  usb.linux.device_number = 5  (0x5)  (int)
  usb.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-8/5-8:1.0'  (string)
  usb.max_power = 100  (0x64)  (int)
  usb.num_configurations = 1  (0x1)  (int)
  usb.num_interfaces = 2  (0x2)  (int)
  usb.num_ports = 0  (0x0)  (int)
  usb.product = 'USB Video Interface'  (string)
  usb.product_id = 6202  (0x183a)  (int)
  usb.speed = 480.0 (480) (double)
  usb.speed_bcd = 294912  (0x48000)  (int)
  usb.vendor = 'Ricoh Co., Ltd'  (string)
  usb.vendor_id = 1482  (0x5ca)  (int)
  usb.version = 2.0 (2) (double)
  usb.version_bcd = 512  (0x200)  (int)


The only way I know this is the right one is because the driver I had to install to get it to work was the r5u870 driver.

BTW, I tried to look for entries with a access_control.file line and most of my sound hardware has those entries but nothing else. In fact there's only about 5 occurences of "Video" or "video" in the entire output of lshal and about 4 of those are in the entries for r5u870 (there's actually two of them for some reason). The other one I'm not sure about but it's entry is something about Video Bus so probably not relevant. I do notice that in both the entries for r5u870 the subsystem is listed as usb instead of video4linux, could that be the problem? Is the driver misconfigured, or maybe v4l not taking precedence when it should?

(In reply to comment #5)
> BTW, I tried to look for entries with a access_control.file line and most of my
> sound hardware has those entries but nothing else. In fact there's only about 5
> occurences of "Video" or "video" in the entire output of lshal and about 4 of
> those are in the entries for r5u870 (there's actually two of them for some
> reason). The other one I'm not sure about but it's entry is something about
> Video Bus so probably not relevant. I do notice that in both the entries for
> r5u870 the subsystem is listed as usb instead of video4linux, could that be the
> problem? 

That's the problem we look explicitly for video4linux devices

> Is the driver misconfigured, or maybe v4l not taking precedence when
> it should?

Don't know

In there an entry for your webcam which specifies which linux device it is using.

E.g. /dev/video0

I'm going to take that last sentence as a question, to which the answer is no. There's no entry in the entire output that lists /dev/video0. The closest to it is the entry for the screen backlight which is "linux.sysfs_path = '/sys/devices/virtual/backlight/acpi_video0'  (string)". It looks like as far as the HAL subsystem is concerned my webcam is just another miscellaneous usb device. I should also mention that the default r5u870 driver doesn't seem to work, and following the advice from this thread ( http://ubuntuforums.org/showthread.php?t=514292 ) I downloaded the latest driver from SVN and installed that. I'm not entirely certain I'd classify my problem as a issue with Cheese, so much as Cheese only supporting the latest most correct way of finding the hardware and either the driver or v4l not working properly. If you're shooting for parity with gstreamer-properties of course this is a problem with Cheese as obviously gstreamer-properties is using a different method to discover and access the v4l2 devices.

(In reply to comment #7)
> I'm going to take that last sentence as a question, to which the answer is no.
> There's no entry in the entire output that lists /dev/video0. The closest to it
> is the entry for the screen backlight which is "linux.sysfs_path =
> '/sys/devices/virtual/backlight/acpi_video0'  (string)". It looks like as far
> as the HAL subsystem is concerned my webcam is just another miscellaneous usb
> device. I should also mention that the default r5u870 driver doesn't seem to

Kyle, I have this same problem. Have you solved it yet or are the cheese people working on it?

Thanks,

Gene

I haven't received any updates on this and I haven't checked for updates to the r5u870 driver, so as far as I know it's still not working for whatever reason. Until I hear otherwise I'm considering it broken. I'll check periodically on the r5u870 driver to see if it's been updated in some way to function better with HAL, assuming it's potentially a problem with the driver, as well as sending an e-mail to the r5u870 driver maintainer so he's aware of what's going on with this. Hopefully this will be cleared up before too much longer as I have a feeling it's just a matter of making the appropriate person aware of the problem.

Figured I might as well reply directly to the bug and CC myself. :)

Yes, from the looks of it, it's just because the webcam is not setup as HAL device. Basically, you'll need to modify the FDI files shipped with your distribution (which come from upstream) and add the USB device to the correct .fdi file (probably /usr/share/hal/fdi/information/10freedesktop/10-xxxx.fdi). Then you can send a diff to the hal-info guys, and your device should be shipped in the next release. I'll probably do this at some later stage (since I have all the device IDs and such), but haven't really had much time, and wasn't even aware this was necessary until now. 

If you'd like to volunteer - it's reasonably simple, I just haven't had time lately - head up an email to the r5u870-list mailing list (sign up @ http://lists.mediati.org/).

*Technically*, this bug is NOTGNOME. However, it might be worth looking into providing users with the option of forcibly enabling the use of the webcam even if it wasn't detected via HAL; so I'm leaving the bug open for now. It might be worth opening a new bug for a feature request for something similar.

Thanks for the explanation, I figured it was something like that. I looked into those fdi files but I really don't know anything about HAL and it would take me a bit of research to understand what exactly I need to do with those files (I browsed through them, but I didn't find any promising entries on my system, most of them seem to deal with keycodes and quirks of suspend mode). I also think it would be a good idea to be able to override the HAL detection in cheese, but as you pointed out that's really a feature request more than it is a bug report so I'm not sure what status that puts this in, and also hinges on whether they want feature parity with gstreamer-properties or not seeing as that's sort of the yardstick the docs use for whether something is a problem with cheese or not.

It freedesktop bug https://bugs.freedesktop.org/show_bug.cgi?id=14809. After a workaround with hal-set-property, cheese works now. However I would suggest cheese say something when no device is detected.

hal-set-property --udi /org/freedesktop/Hal/devices/usb_device_46d_870_noserial --key info.capabilities --strlist-pre video4linux
hal-set-property --udi /org/freedesktop/Hal/devices/usb_device_46d_870_noserial --key video4linux.device --string /dev/video0

so it works with the workaround you mentioned above? should i add it to the cheese faq?

cheese 2.24 will display further info about non detected webcams

Well it's up to you. If a lot of people own a Quickcam, then maybe yes. Note that udi may change if others' webcam is not the same as mine.

Have just tried this on my Vaio SZ using the r5u870 driver and an adapted version of the hal command in comment 12 works (i.e. changing the device to usb_device_5ca_1830_noserial).

I asked on the #hal IRC channel and people on there suggested the driver should be setting these properties.  I reported a bug on the r5u870 site.

Just have stumbled upon this issue with a Sony VGN-TZ31WN VAIO.

This is indeed the r5u870 driver's issue which results in HAL not exposing the video4linux capabilities and thus cheese failing detection.

I have attached a FDI file you can throw into your distro HAL folder to temporarily fix this for all r5u780 cameras until the module is fixed upstream (I'll try to provide a patch there...).

Example target filepath (requires HAL restart):
/etc/hal/fdi/information/20thirdparty/10-ricoh-r5u870-cam.fdi

Cheese works fine then.

Feel free to mark as INVALID/WONTFIX.

Created attachment 116000 [details]
HAL FDI file to fix v4l properties for Ricoh r5u870 based webcams

Put into your <hal-fdi-dir>/information/20thirdparty/ directory and restart HAL.

that won't be accepted upstream, I guess. Those information should be taken from /sys (for example /dev/video0 won't be a fixed value)

Did any of you reported this issue to the kernel driver maintainers?
I think they are the ones who should solve it. There is probably something wrong with the driver's v4l support if hal doesn't see it as video4linux.
You can find them at:
http://wiki.mediati.org/Support
Feel free to point them to this bug.

Ops, I just seen that bloch already reported the issue to their bug tracker.
http://bugs.mediati.org/r5u870/issue17
Please confirm, subscribe to that bug and follow the discussion there.
If you want let us know if there is any progress.

Actually Filippo, I'm already CC'ed on this bug. :)
I'm hoping to get this implemented this weekend upstream, but I believe this also affects some of the Logitech cameras (see the Freedesktop bug).

Anyway, I as I said earlier, the reason I've left this bug open is because it might be worth looking into providing users with the option of forcibly enabling the use of the webcam even if it wasn't detected via HAL.

Daniel, if you can elaborate as to what you meant by "cheese 2.24 will display further info about non detected webcams", I'll happily close this bug and try and fix it upstream.

Martin, also, the correct solution is to patch the actual driver rather than have a HAL FDI fix, however, it certainly works in the meantime.

Alexander, I'm sorry I should have read the whole history before to comment.
I didn't notice your comment ;).

I don't think the feature you suggest would be good. I see that's quite an hack.
We support video4linux devices through hal.
Hal should correctly expose their capability.
The kernel driver should do things right to make this possible.
If this doesn't happen it's not up to cheese to solve this just to support more webcams.
One of the good things of freesoftware is that projects can easily intercommunicate so that bugs can be solved in the right place.
Am I wrong?

Sounds reasonable.
Just out of interest, why do we need to query HAL for this stuff? Older Cheese releases just used the GStreamer v4l(2)src elements for that. :)

*** Bug 523435 has been marked as a duplicate of this bug. ***

>why do we need to query HAL for this stuff?
We don't *need* hal, we *want* hal because its aim is to make application-hardware interaction easier providing a way to easily detect available devices and their capabilities.
If you want to know more about hal, why it exists and why it should be used, you can take a look here:
http://www.freedesktop.org/wiki/Software/hal
So the real question is.. why a kernel driver shouldn't do things right to make the whole thing work?

Anyway, did any progress with the issue in upstream driver?

*** Bug 547396 has been marked as a duplicate of this bug. ***

I noticed today that cheese recognizes my webcam with r5u870 driver, HP tx1320us. The bug marked as duplicate to this has been solved.

Alexander, could you confirm this?

By "I noticed today that cheese recognizes" I meant of course it didn't previously. And finally cheese works for me :) Hope it works for Alexander also. The bug I submitted marked as a duplicate is just 2-3 comments before *this* one. Regards and thanks for support.

Michał, I asked Alexander for a confirm because he's the driver developer!

Yeah, I personally can't see how it'd magically work, unless the HAL people got tired! :)

Anyway, I'm making some progress upstream, so, should I just mark this bug as NOTGNOME and close?

marking as NOTGNOME

*** Bug 552998 has been marked as a duplicate of this bug. ***

*** Bug 553588 has been marked as a duplicate of this bug. ***

*** Bug 585900 has been marked as a duplicate of this bug. ***

Alexander, several other out of tree drivers had this very same issue and most of all were easily fixed but a one line commit. It seems that the bug comes from this change in videodev http://linuxtv.org/hg/v4l-dvb/rev/db7029e2fe8c 
All in tree drivers were updated to reflect it but most out of tree drivers stopped working with HAL.
See also my comments in bug #583733