New interface requirement: dvb

I’ve been working on snapping TVHeadend. This service interacts with hardware under the /dev/dvb directory for TV Capture cards (at least in Europe - I don’t know if the US ATSC cards have a different dev namespace). Specifically it needs write access to /dev/dvb/adapter<n>/frontend<i> where n and i are numbers indicating the adapter and frontend on the adapter to allow for multiple cards and multiple tuners per card.

Also needed is read access to /dev/dvb/adapter<n>/dvr<i> and write access to /dev/dvb/adapter<n>/demux<i>.

= AppArmor =
Time: Jan 11 15:35:01
Log: apparmor="ALLOWED" operation="open" profile="snap.tvheadend.tvheadend" name="/dev/dvb/adapter1/frontend0" pid=22807 comm="tvheadend" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
File: /dev/dvb/adapter1/frontend0 (write)

= AppArmor =
Time: Jan 11 15:35:01
Log: apparmor="ALLOWED" operation="open" profile="snap.tvheadend.tvheadend" name="/dev/dvb/adapter0/frontend0" pid=22807 comm="tvheadend" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
File: /dev/dvb/adapter0/frontend0 (write)

= AppArmor =
Time: Jan 11 15:37:24
Log: apparmor="ALLOWED" operation="open" profile="snap.tvheadend.tvheadend" name="/dev/dvb/adapter0/dvr0" pid=22807 comm="tvh:lnxdvb-fron" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
File: /dev/dvb/adapter0/dvr0 (read)

= AppArmor =
Time: Jan 11 15:37:24
Log: apparmor="ALLOWED" operation="open" profile="snap.tvheadend.tvheadend" name="/dev/dvb/adapter0/demux0" pid=22807 comm="tvh:lnxdvb-fron" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
File: /dev/dvb/adapter0/demux0 (write)

(note they’re listed as ALLOWED in the log above due to devmode)

3 Likes

This feels very similar to me as the transitional optical-drive interface. @niemeyer, how do you feel about a new transitional interface called dvb?

Here is some information on

I’m not sure I quite understand what you mean by “transitional” interface. Are you expecting DVB hardware to cease to exist and thus the interface to go away naturally when that happens?

It sounds good to have an interface to handle this, but I’m also not sure I understand what transitional means in this case.

The dvb name doesn’t sound so great for this, though. Few will be able to tell what that means without searching for it. Something like “video-broadcasting” might be more friendly.

This also makes me want to have aliases for interfaces, so that those that know the underlying name can use it.

That’s an idea. There are other broadcast methods in use and so I guess they’re likely to use different device files. I’m primarily aware that in North America the broadcast mechanism is ATSC instead of DVB, though I don’t know how an appropriate adapter is exposed by the Linux kernel.

“optical-drive” is considered transitional because it uses glob rules for assigning all optical drives to the snap, rather than assigning specific devices to the snap.

Similarly, “dvb” would be transitional with glob rules instead of assigning specific TV cards, etc.

I was trying to think that through and came up with “dvb” since, in my mind, we would only allow the dvb interfaces. This is in an effort to sidestep the fact that some video broadcasting devices show up with v4l, which is already allowed by the ‘camera’ transitional interface (again, transitional because of glob rules rather than per-device assignment). If we name it “video-broadcasting”, or similar, I think we would also need to allow the v4l devices as per https://www.linuxtv.org/wiki/index.php/Device_nodes_and_character_devices. We would then have overlap of /dev/video* rules via two interfaces, which if these are transitional interfaces is perhaps ok, but with some future per-device/per-snap assignment, we wouldn’t want.

We can’t allow a video-broadcasting interface to look at local cameras into people’s homes. The choices are very different privacy-wise.

Which broadcasting boards show up as v4l? How can people tune those devices?

Regarding the name, I suggest to use the official one if just dvb is too short: digital-video-broadcasting

If this was not a transitional interface, who would assign names? The DVB device often come with USB interface, so they can be plugged in any time. The typical use case is a Ubuntu Core device with tvheadend acting as a SatIP server.

my usecase is kodi and vdr and i’d appreciate if we could simply start out with a /dev/dvb* only interface (i have quite a bunch of dvb cards here and have not seen any that actually create /dev/video* … but then thats only by european standards, perhaps it is required for cards in other regions).

after all the camera interface already provides access to /dev/video* and other v4l related devices so if people want/need that they can use a combination of these two interfaces.

the other devices mentioned in the document above (teletext, radio and vbi) could even have their own separate interfaces given how specific their respective tasks are.

1 Like

DVB devices will often register an additional input device when they have an IR receiver. Here is an example dmesg output:

`

[ 2192.808475] usb 1-12: new high-speed USB device number 2 using xhci_hcd
[ 2193.029177] usb 1-12: New USB device found, idVendor=2013, idProduct=024c
[ 2193.029179] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2193.029180] usb 1-12: Product: PCTV 460e
[ 2193.029182] usb 1-12: Manufacturer: PCTV Systems
[ 2193.029183] usb 1-12: SerialNumber: 00000010FJZT
[ 2194.043382] media: Linux media interface: v0.10
[ 2194.049113] Linux video capture interface: v2.00
[ 2194.058263] em28xx 1-12:1.0: New device PCTV Systems PCTV 460e @ 480 Mbps (2013:024c, interface 0, class 0)
[ 2194.058267] em28xx 1-12:1.0: DVB interface 0 found: isoc
[ 2194.060292] em28xx 1-12:1.0: chip ID is em28174
[ 2194.487330] em28xx 1-12:1.0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x0b6e32f6
[ 2194.487333] em28xx 1-12:1.0: EEPROM info:
[ 2194.487334] em28xx 1-12:1.0: microcode start address = 0x0004, boot configuration = 0x01
[ 2194.533335] em28xx 1-12:1.0: No audio on board.
[ 2194.533336] em28xx 1-12:1.0: 500mA max power
[ 2194.533338] em28xx 1-12:1.0: Table at offset 0x39, strings=0x1aa0, 0x14ba, 0x1ace
[ 2194.533404] em28xx 1-12:1.0: Identified as PCTV DVB-S2 Stick (460e) (card=80)
[ 2194.533406] em28xx 1-12:1.0: dvb set to isoc mode.
[ 2194.533464] usbcore: registered new interface driver em28xx
[ 2194.544300] em28xx 1-12:1.0: Binding DVB extension
[ 2194.594342] tda10071 13-0055: NXP TDA10071 successfully identified
[ 2194.603346] a8293 13-0008: Allegro A8293 SEC successfully attached
[ 2194.603352] dvbdev: DVB: registering new adapter (1-12:1.0)
[ 2194.603354] em28xx 1-12:1.0: DVB: registering adapter 0 frontend 0 (NXP TDA10071)…
[ 2194.603639] em28xx 1-12:1.0: DVB extension successfully initialized
[ 2194.603640] em28xx: Registered (Em28xx dvb Extension) extension
[ 2194.609894] em28xx 1-12:1.0: Registering input extension
[ 2194.648476] Registered IR keymap rc-pinnacle-pctv-hd
[ 2194.657384] rc rc0: 1-12:1.0 IR as /devices/pci0000:00/0000:00:01.1/0000:01:00.0/usb1/1-12/1-12:1.0/rc/rc0
[ 2194.657427] input: 1-12:1.0 IR as /devices/pci0000:00/0000:00:01.1/0000:01:00.0/usb1/1-12/1-12:1.0/rc/rc0/input19
[ 2194.657496] em28xx 1-12:1.0: Input extension successfully initialized
[ 2194.657497] em28xx: Registered (Em28xx Input Extension) extension

`

And there is one more thing: DVB supports transport of network packages. The relevant device file is /dev/dvb/adapter<x>/net<y>. Should this be a separate interface?
In principle we could have dvb-video and dvb-network, since the use case is a different one.

I don’t think an IR input should be included in the DVB interface specification because it is orthogonal despite being provided by the same device. IR input, if it is not covered via standard keyboard semantics should be a separate additional interface.

I think you are correct that the networking capability should be covered via a different interface to TV reception.

Created a PR today: https://github.com/snapcore/snapd/pull/4700

1 Like

Sorry for taking a while to get to it. Our review queue was unreasonable due to parallel activities, but we’re now getting it back to sane levels. This PR is unblocked, we have a suggested name, and should get a review from @jdstrand shortly so that it can go in.

2 Likes

I updated the PR with the requested changes.

I noticed a mention of atsc tuners in the initial post. I use pcie devices. HVR-1250’s. I’ve never been able to make them work with TvHeadend. They just are not seen by TvHeadend. I can see them in /dev/dvb/adapterX. They also function correctly in Mythtv so I know they work. I have the snap installed. Inside the TV adapters tab I can see a folder labeled TV adapters. It is unresponsive to clicks. Is this where I should be able to configure the hardware device?

You need to connect the dvb interface if you haven’t yet, because I’ve not requested auto connection:

sudo snap connect tvheadend:dvb

That did it. I can now select the the tuner. I will work through the TvHeadend configuration. Thank you.