Public bug reported:

On Qualcomm Snapdragon laptops we are depending on libcamera for the
built-in webcam. This is supported in pipewire via libspa-0.2-libcamera
and works in theory.

On user login there is an ordering problem where wireplumber.service
starts before udev changes ownership of /dev/media* and /dev/udmabuf to
make them user accessible, causing the camera to not be detected:

Sep 02 15:54:46 t14s wireplumber[4218]: [0:00:18.540654888] [4314] ERROR 
MediaDevice media_device.cpp:483 /dev/media0[]: Failed to open media device at 
/dev/media0: Permission denied
Sep 02 15:54:46 t14s wireplumber[4218]: [0:00:18.540686086] [4314]  INFO 
DeviceEnumerator device_enumerator.cpp:224 Unable to populate media device 
/dev/media0 (Permission denied), skipping
Sep 02 15:54:46 t14s wireplumber[4218]: [0:00:18.540693013] [4314]  WARN 
DeviceEnumerator device_enumerator_udev.cpp:174 Failed to add device for 
'/sys/devices/platform/soc@0/acb6000.isp/media0', skipping
Sep 02 15:54:46 t14s wireplumber[4218]: [0:00:18.542468169] [4314] ERROR 
DmaBufAllocator dma_buf_allocator.cpp:119 Could not open any dma-buf provider

This can be fixed with a manual restart of the user service.

A temporary solution could be something similar to network-wait-
online.service that wireplumber depends on to make sure the devices are
available before it starts.

Ultimately it might make more sense for wireplumber/pipewire to monitor
/dev ownership changes and update if necessary.

From https://www.freedesktop.org/wiki/Software/systemd/multiseat/:

If you are writing user-level software interfacing directly with kernel
drivers (like PulseAudio), consider ignoring seat information
completely, and make available to the user all devices he/she can
access. A device that a user cannot access is a device that is not
assigned to any of the seats he is currently active on. In order to
track changes when sessions come and go (and are activated/deactivated)
consider watching the devices nodes with inotify so that you are
notified when the access mode changes. This scheme works only if your
software runs under the user ID of the user himself!

** Affects: ubuntu-x13s-settings (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: ubuntu-x1e-settings (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: wireplumber (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: ubuntu-x13s-settings (Ubuntu Questing)
     Importance: Undecided
         Status: New

** Affects: ubuntu-x1e-settings (Ubuntu Questing)
     Importance: Undecided
         Status: New

** Also affects: ubuntu-x13s-settings (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: ubuntu-x1e-settings (Ubuntu)
   Importance: Undecided
       Status: New

** Also affects: ubuntu-x13s-settings (Ubuntu Questing)
   Importance: Undecided
       Status: New

** Also affects: ubuntu-x1e-settings (Ubuntu Questing)
   Importance: Undecided
       Status: New

** Also affects: Ubuntu Questing
   Importance: Undecided
       Status: New

** No longer affects: ubuntu

** No longer affects: Ubuntu Questing

** Also affects: wireplumber (Ubuntu)
   Importance: Undecided
       Status: New

** Description changed:

  On Qualcomm Snapdragon laptops we are depending on libcamera for the
  built-in webcam. This is supported in pipewire via libspa-0.2-libcamera
  and works in theory.
  
  On user login there is an ordering problem where wireplumber.service
  starts before udev changes ownership of /dev/media* and /dev/udmabuf to
- make them user accessible, causing the camera to not be detected. This
- can be fixed with a manual restart of the user service.
+ make them user accessible, causing the camera to not be detected:
  
- A temporary solution could be something similar to 
network-wait-online.service that wireplumber depends on to make sure the 
devices are available before it starts.
- Ultimately it might make more sense for wireplumber/pipewire to monitor /dev 
ownership changes and update if necessary.
+ Sep 02 15:54:46 t14s wireplumber[4218]: [0:00:18.540654888] [4314] ERROR 
MediaDevice media_device.cpp:483 /dev/media0[]: Failed to open media device at 
/dev/media0: Permission denied
+ Sep 02 15:54:46 t14s wireplumber[4218]: [0:00:18.540686086] [4314]  INFO 
DeviceEnumerator device_enumerator.cpp:224 Unable to populate media device 
/dev/media0 (Permission denied), skipping
+ Sep 02 15:54:46 t14s wireplumber[4218]: [0:00:18.540693013] [4314]  WARN 
DeviceEnumerator device_enumerator_udev.cpp:174 Failed to add device for 
'/sys/devices/platform/soc@0/acb6000.isp/media0', skipping
+ Sep 02 15:54:46 t14s wireplumber[4218]: [0:00:18.542468169] [4314] ERROR 
DmaBufAllocator dma_buf_allocator.cpp:119 Could not open any dma-buf provider
+ 
+ This can be fixed with a manual restart of the user service.
+ 
+ A temporary solution could be something similar to network-wait-
+ online.service that wireplumber depends on to make sure the devices are
+ available before it starts.
+ 
+ Ultimately it might make more sense for wireplumber/pipewire to monitor
+ /dev ownership changes and update if necessary.
+ 
+ From https://www.freedesktop.org/wiki/Software/systemd/multiseat/:
+ 
+ If you are writing user-level software interfacing directly with kernel
+ drivers (like PulseAudio), consider ignoring seat information
+ completely, and make available to the user all devices he/she can
+ access. A device that a user cannot access is a device that is not
+ assigned to any of the seats he is currently active on. In order to
+ track changes when sessions come and go (and are activated/deactivated)
+ consider watching the devices nodes with inotify so that you are
+ notified when the access mode changes. This scheme works only if your
+ software runs under the user ID of the user himself!

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2122049

Title:
  wireplumber starts before camera is user accessible

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-x13s-settings/+bug/2122049/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to