Bug 244880 - multimedia/webcamd: Never creates device nodes if HAL is enabled
Summary: multimedia/webcamd: Never creates device nodes if HAL is enabled
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Hans Petter Selasky
URL:
Keywords: needs-qa
Depends on: 244958
Blocks:
  Show dependency treegraph
 
Reported: 2020-03-18 05:29 UTC by Patrick McMunn
Modified: 2021-02-08 11:02 UTC (History)
3 users (show)

See Also:
koobs: maintainer-feedback? (hselasky)


Attachments
ktrace.out (175.99 KB, application/octet-stream)
2020-03-18 22:29 UTC, Patrick McMunn
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick McMunn 2020-03-18 05:29:36 UTC
I'm trying to get both a USB gamepad and the webcam in my laptop working with webcamd. I'm running Plasma 5 on FreeBSD 12.1-RELEASE.

I have hald_enable="YES" in my /etc/rc.conf.local file. The RC script supplied with webcamd detects whether HAL is enabled and, if it is, automatically adds the -H flag (which enabled HAL support) to the parameters passed to webcamd upon starting. This is probably fine if everything is working as expected, but that isn't the case.

webcamd was not creating /dev/input/js0 for my gamepad or /dev/video0 for my webcam when I started it via the RC script. However, when I started webcamd directly from the commandline, it did. So I tried passing the -H flag to webcamd, and it just kept emitting the message "Waiting for HAL connection." on the console.

For whatever reason, webcamd is never connecting to HAL and just gets stuck waiting for a connection to HAL thus never creating any device nodes. So the current workarounds I've found, if using webcamd via the RC script, is to disable HAL in /etc/rc.conf or to comment out the HAL autodetection section in webcamd's RC script.
Comment 1 Hans Petter Selasky freebsd_committer freebsd_triage 2020-03-18 07:46:03 UTC
Can you do a ktrace on webcamd, to figure out why it doesn't connect to hal?

--HPS
Comment 2 Patrick McMunn 2020-03-18 22:28:55 UTC
I've never used ktrace before, so I had to read the man page. I hope I used it correctly. I started hal with "service hald start" then ran "ktrace -tcnisuw -i webcamd -N Logitech-Logitech-Dual-Action -M 0 -H" from the command line. But even though there are some /var/run/hald/dbus-xxxxxxxxxx files with the timestamp of when I started hal, I can't find in top or KDE's system monior any sign that hal is remaining resident after starting it. So maybe hal is starting and immediately exiting for some reason?
Comment 3 Patrick McMunn 2020-03-18 22:29:45 UTC
Created attachment 212515 [details]
ktrace.out
Comment 4 Patrick McMunn 2020-03-21 17:29:42 UTC
This appears that it may just be a hald issue and not a webcamd issue. Hal is indeed crashing, so I opened a bug for hald crashing on startup. It's bug 244958.
Comment 5 Hans Petter Selasky freebsd_committer freebsd_triage 2020-10-17 17:54:21 UTC
Hi,

Is hald installed in your system?

ps auxw | grep hal

--HPS
Comment 6 Patrick McMunn 2020-10-21 02:37:20 UTC
I followed up on the HAL bug I filed. HAL is no longer crashing and I haven't been able to reproduce the crash. Since this turned out to be primarily an issue with HAL, maybe this should be closed. The only suggestion I would have is, if possible, implement either a fallback mechanism or maybe have a timeout period and emit an error message if webcamd is unable to connect to HAL. A fallback mechanism would probably result in just masking an issue if one were to occur and it not being discovered. At least if it failed and exited with something like "Unable to connect to HAL. Is HAL running?" it could provide enough information to a user to pinpoint the problem if HAL were to act up again.
Comment 7 Mateusz Piotrowski freebsd_committer freebsd_triage 2021-02-08 11:02:20 UTC
HAL has been removed from the ports tree in https://svnweb.freebsd.org/ports?view=revision&revision=564691. I'm closing this issue for now because of that.