Re: Remote for the DViCO FusionHDTV DVB-T Dual Digital card

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I demand that Dyks, Axel (XL) may or may not have sent directly to me despite
my setting the M-F-T header to point only to the list...

> Darren Salt wrote:
>> I demand that Dyks, Axel (XL) may or may not have written...
>>> Darren Salt wrote:
>>>> I demand that Dyks, Axel (XL) may or may not have written...
>>>>> The later (dev/input) worked for me at least after enabling "input
>>>>> device events" (INPUT_EVDEV=y) in the kernel. [...]
>>>>> Furthermore it seems to be a good idea to add a "udev" rule that
>>>>> creates a symlink for the "event device" of your remote. [...]
>>>> You might have /dev/input/by-id/* and /dev/input/by-name/*, but I find
>>>> that by-id isn't populated for DVB IR whereas by-name isn't stable
>>>> despite no change in the number or location of the devices.
>>> No, I haven't. [...]
>> They're provided by /etc/udev/rules.d/z20_persistent-input.rules (which
>> points to ../persistent-input.rules) in current Debian testing/unstable.

> Ah ... I'm on gentoo, which obviously does not provide those rules ...
> Anyway, I was refering to the sysfs nodes that are less likely to
> depend on the distribution than on the kernel (version) ...

Hmm? All that I see of use (wrt the problem at hand) there are the 'name' and
'phys' files, and that information can also be acquired via ioctls on the
device nodes.

And the 'name' files' contents are truncated, at least for my Nova-Ts.
(cx88-input.c line 42, "char name[32]", is the cause.)

>>>> While I could use udev rules, I prefer this patch:
>>>> <URL:http://sourceforge.net/tracker/?func=detail&atid=305444&aid=1434830&group_id=5444>
>>> Hmmh ... why should someone want to apply a patch, if the solution comes
>>> out of the (udev) box? Maybe I've got you wrong, but presently I can't
>>> follow your argument.

>> Alternative methods; for one thing, not everybody is using udev.

> Hmm... that's an argument? ...

I *could* be reasoning in my spare time.

>> In my case, it needs to be done on the card's physical location because I
>> have two identical cards; if I move the card with the in-use IR interface,
>> I still have to update the configuration anyway, and having lircd look at
>> the available input device nodes means that I don't have to remember to
>> recreate a symlink.

> ... OK this one counts. :-)

:-)

>> (Also, I prefer /dev/hda to /dev/disk/... which reminds me a lot of
>> devfs's long paths.)

> ... as long as you are not hot-plugging your disks ... :-)

Not possible here - well, USB aside... :-)

> ByTheWay: We are "sightly" drifting away from the original topic and I'm
> afraid that our discussion tends to become absolutely useless ... though I
> must admit that it's a lot of fun, and ... if we try really hard we might
> be able to beat the all-time-thread-length-record (see the "Multi protocol
> support / DVB-S2 API" thread which definitely will make it into the hall of
> fame)

Maybe. I won't mention the "thread of evil" in comp.sys.sinclair, then...
oops...

> Cheers -- at least you may demand that I may or may not have said this ...

No. I may or may not demand it... :-)

> P. S.: May I deduce that you are able to explain why the sofa irreversibly
>        stuck on the staircase?

A mention of Shada will suffice, I think...

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Lobby friends, family, business, government.    WE'RE KILLING THE PLANET.

"Sausages! Get your sausages inna bun! Genuine pig parts!"

_______________________________________________

linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux