101 replies to this topic

[Erik Slagter]

 

# There are a number of modifiers that are allowed to be used in some
# of the different fields. They provide the following subsitutions:
#
# %n the "kernel number" of the device.
#    For example, 'sda3' has a "kernel number" of '3'
# %e the smallest number for that name which does not matches an existing node
# %k the kernel name for the device
# %M the kernel major number for the device
# %m the kernel minor number for the device
# %b the bus id for the device
# %c the string returned by the PROGRAM
# %s{filename} the content of a sysfs attribute
# %% the '%' char itself

# The first rtc device is symlinked to /dev/rtc
KERNEL=="rtc0", SYMLINK+="rtc"

# Legacy paths for dbox devices
KERNEL=="oled0", SYMLINK+="dbox/oled0"
KERNEL=="fp0", SYMLINK+="dbox/fp0"
KERNEL=="lcd0", SYMLINK+="dbox/lcd0"
KERNEL=="vtuner0", SYMLINK+="misc/vtuner0"
KERNEL=="vtuner1", SYMLINK+="misc/vtuner1"
KERNEL=="vtuner2", SYMLINK+="misc/vtuner2"
KERNEL=="vtuner3", SYMLINK+="misc/vtuner3"
KERNEL=="vtuner4", SYMLINK+="misc/vtuner4"
KERNEL=="vtuner5", SYMLINK+="misc/vtuner5"
KERNEL=="vtuner6", SYMLINK+="misc/vtuner6"
KERNEL=="vtuner7", SYMLINK+="misc/vtuner7"
KERNEL=="vtuner8", SYMLINK+="misc/vtuner8"
KERNEL=="vtuner9", SYMLINK+="misc/vtuner9"
KERNEL=="vtuner10", SYMLINK+="misc/vtuner10"
KERNEL=="vtuner11", SYMLINK+="misc/vtuner11"
KERNEL=="pvr", SYMLINK+="misc/pvr"
KERNEL=="i2c-[0-9]*", SYMLINK+="i2c/%n"

# The first framebuffer is symlinked to /dev/fb
KERNEL=="fb0", SYMLINK+="fb/0"

# Make all input devices read-write to the input group
SUBSYSTEM=="input", GROUP="input", MODE="660"

AFAIK all of these are already in, so I don't see what makes the difference?

The current localextra.rules only allows for 4 vtuners, and the Edision MIO can do a lot more than that.
https://github.com/O...ocalextra.rules

 

Still I don't think that explains why your additional tuner doesn't work. First of all, a "normal" (DVB4Linux API compatible) tuner does NOT take up a vtuner. Some, notably SUNDTEK, tuners have their support in userspace, so they do need a vtuner, one of them. The only other use of vtuners I can think of is SAT>IP.

 

There is an easy way to check by creating the symlinks to the device nodes yourself, it doesn't NEED to be done by udev, it's just more convenient that way.

[rantanplan]

hello Erik


You yourself expanded the local routes by 4 VTuners, because you noticed it with the VU + receivers.

No external USB tuner would work without this extension.
A peculiarity of the UDEV.
The number of virtually possible tuners comes from the driver and the kernel used.
If the number is wrong, then more mistakes will obviously occur.

If you use mdev this is done a little easier by the busybox mdev without any problems.

If you also use UDEV for this, you seem to have to specify an assignment.
Hence my question as to whether the assignment is statically useful, or whether using the variable '% n' would not be better.
I can't test this, so people with the appropriate hardware would have to test it.


greetings

Edited by rantanplan, 4 October 2020 - 10:02.

[Erik Slagter]

It will probably work, I'll have to check.

 

But in 9 lines of text, you completely ignored all of my other text, where I wrote that I can hardly imagine that the amount of vtuners is the actual issue, as this tuner probably doesn't use one, and if it does, there are still three left.

[rantanplan]

I have the assumption that, depending on the kernel, an assignment of the V-Tuner does not correspond to the sequence of the numbers.

That would mean that a single USB tuner could also be assigned a (for example) V-Tuner 7, although 1-6 are not assigned.

[el bandido]

Perhaps the tuner assignment can also be displayed freely variable instead of the static assignment.

 

 

KERNEL=="vtuner0", SYMLINK+="misc/vtuner0"
KERNEL=="vtuner1", SYMLINK+="misc/vtuner1"
KERNEL=="vtuner2", SYMLINK+="misc/vtuner2"
KERNEL=="vtuner3", SYMLINK+="misc/vtuner3"
KERNEL=="vtuner4", SYMLINK+="misc/vtuner4"
KERNEL=="vtuner5", SYMLINK+="misc/vtuner5"
KERNEL=="vtuner6", SYMLINK+="misc/vtuner6"
KERNEL=="vtuner7", SYMLINK+="misc/vtuner7"
KERNEL=="vtuner8", SYMLINK+="misc/vtuner8"
KERNEL=="vtuner9", SYMLINK+="misc/vtuner9"
KERNEL=="vtuner10", SYMLINK+="misc/vtuner10"
KERNEL=="vtuner11", SYMLINK+="misc/vtuner11"

change with

KERNEL=="vtuner%n", SYMLINK+="misc/vtuner%n"

I don't know if that will work.
just an idea
 

Like this?
# The first rtc device is symlinked to /dev/rtc
KERNEL=="rtc0", SYMLINK+="rtc"

# Legacy paths for dbox devices
KERNEL=="oled0", SYMLINK+="dbox/oled0"
KERNEL=="fp0", SYMLINK+="dbox/fp0"
KERNEL=="lcd0", SYMLINK+="dbox/lcd0"
KERNEL=="vtuner%n", SYMLINK+="misc/vtuner%n"
KERNEL=="pvr", SYMLINK+="misc/pvr"
KERNEL=="i2c-[0-9]*", SYMLINK+="i2c/%n"

 

[rantanplan]

yes that's how it is meant.
You have the box with the latest kernel and driver, so it is a reference for such tests (from my point of view).
Conversely, you would have to test it with an old kernel and driver.
The xtrend would be a good choice.
But I don't know whether the tuners will be addressed correctly.
If this 'placeholder' worked, it would certainly be easy to use with Udev.
Try to build it and see if it works.

# There are a number of modifiers that are allowed to be used in some
# of the different fields. They provide the following subsitutions:
#
# %n the "kernel number" of the device.
#    For example, 'sda3' has a "kernel number" of '3'
# %e the smallest number for that name which does not matches an existing node
# %k the kernel name for the device
# %M the kernel major number for the device
# %m the kernel minor number for the device
# %b the bus id for the device
# %c the string returned by the PROGRAM
# %s{filename} the content of a sysfs attribute
# %% the '%' char itself

# The first rtc device is symlinked to /dev/rtc
KERNEL=="rtc0", SYMLINK+="rtc"

# Legacy paths for dbox devices
KERNEL=="oled0", SYMLINK+="dbox/oled0"
KERNEL=="fp0", SYMLINK+="dbox/fp0"
KERNEL=="lcd0", SYMLINK+="dbox/lcd0"
KERNEL=="vtuner%n", SYMLINK+="misc/vtuner%n"
KERNEL=="pvr", SYMLINK+="misc/pvr"
KERNEL=="i2c-[0-9]*", SYMLINK+="i2c/%n"

# The first framebuffer is symlinked to /dev/fb
KERNEL=="fb0", SYMLINK+="fb/0"

# Make all input devices read-write to the input group
SUBSYSTEM=="input", GROUP="input", MODE="660"

 

[Dimitrij]

 

KERNEL=="vtuner%n", SYMLINK+="misc/vtuner%n"

It works for me, solo4K.

[Erik Slagter]

I have the assumption that, depending on the kernel, an assignment of the V-Tuner does not correspond to the sequence of the numbers.
That would mean that a single USB tuner could also be assigned a (for example) V-Tuner 7, although 1-6 are not assigned.

 

I understand what you say, but I don't think that is likely.

 

If only because most receivers only offer 4 vtuners.

Edited by Erik Slagter, 8 October 2020 - 17:02.

[Erik Slagter]

 

 

KERNEL=="vtuner%n", SYMLINK+="misc/vtuner%n"

It works for me, solo4K.

 

Well let's apply it then. I still don't think it's going to help TS but it won't hurt and is nicer.

[Dimitrij]

Sorry, Erik, I gave the wrong information.

Connect AVerMedia AVerTV Volar HD/PRO (A835).

With this option, the tuner is not detected:

KERNEL=="vtuner%n", SYMLINK+="misc/vtuner%n"

With this option,tuner detected:

KERNEL=="vtuner0", SYMLINK+="misc/vtuner0"
KERNEL=="vtuner1", SYMLINK+="misc/vtuner1"
KERNEL=="vtuner2", SYMLINK+="misc/vtuner2"
KERNEL=="vtuner3", SYMLINK+="misc/vtuner3"
KERNEL=="vtuner4", SYMLINK+="misc/vtuner4"
KERNEL=="vtuner5", SYMLINK+="misc/vtuner5"
KERNEL=="vtuner6", SYMLINK+="misc/vtuner6"
KERNEL=="vtuner7", SYMLINK+="misc/vtuner7"
KERNEL=="vtuner8", SYMLINK+="misc/vtuner8"
KERNEL=="vtuner9", SYMLINK+="misc/vtuner9"
KERNEL=="vtuner10", SYMLINK+="misc/vtuner10"
KERNEL=="vtuner11", SYMLINK+="misc/vtuner11"

openpli develop vusolo4k

vusolo4k login: root
root@vusolo4k:~# cat /proc/bus/nim_sockets
NIM Socket 0:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(7376 FBC)
        Frontend_Device: 0
NIM Socket 1:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(7376 FBC)
        Frontend_Device: 1
NIM Socket 2:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(7376 FBC)
        Frontend_Device: 2
NIM Socket 3:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(7376 FBC)
        Frontend_Device: 3
NIM Socket 4:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(7376 FBC)
        Frontend_Device: 4
NIM Socket 5:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(7376 FBC)
        Frontend_Device: 5
NIM Socket 6:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(7376 FBC)
        Frontend_Device: 6
NIM Socket 7:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(7376 FBC)
        Frontend_Device: 7
NIM Socket 8:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(AVL6222)
        Frontend_Device: 8
        I2C_Device: 4
NIM Socket 9:
        Type: DVB-S2
        Name: Vuplus DVB-S NIM(AVL6222)
        Frontend_Device: 9
        I2C_Device: 4

NIM Socket 10:
        Type: DVB-T
        Name: Sundtek DVB-T (III) (2/0) (USB):VTUNER
        Frontend_Device: 10
NIM Socket 11:
        Type: DVB-S2
        Name: Sundtek DVB-S/S2 (IV) (0/0) (USB):VTUNER
        Frontend_Device: 11
NIM Socket 12:
        Type: DVB-T
        Name: A835:VTUNER

 

Edited by Dimitrij, 8 October 2020 - 19:10.

[rantanplan]

OK,
so only static assignment works?

I can't test it, you would have to rely on the users with the hardware.
The image building is displayed perfectly in both, but I don't know whether the tuners are working.
The static tuner assignment from 0-11 (= 12 Vtuner) also corresponds to the number that is otherwise automatically generated by the mdev.
So I suspect that this number is necessary and correct.
Maybe you should first adapt it that way.
greetings

[athoik]

I think you need to try this one:


KERNEL=="vtuner[0-9]*", SYMLINK+="misc/vtuner%n"

[Dimitrij]

I think you need to try this one:


KERNEL=="vtuner[0-9]*", SYMLINK+="misc/vtuner%n"

Thanks,it work

Edited by Dimitrij, 10 October 2020 - 07:29.

[Dimitrij]

[udev] localextra.rules add more vtuner

[WanWizard]

Merged.

[Erik Slagter]

You guys beat me to it   (I wasn't really quick...)

 

And now the interesting question, does this adjustment solve the TS'es issue?

[el bandido]

I am still using mdev.
Will build an image using the latest OpenPLi updates and see if mdev is still needed. Thanks.

[el bandido]

On a fresh build of  the Development branch using a MIO+ receiver and the Hauppauge atsc tuner, I still have to add mdev or the receiver will crash.

Thanks.

[WanWizard]

Same crash? Different crash?

[el bandido]

The crash logs seems to be identical.
I will post a new crash log later today.
 

Thanks.