Ideas para PipeManagement v3 (CUSTOM 3)

Hi Vic,

My very first USB dongles were managed in a "serial" way. But I don't know if it is still the case.
Seems you would need MAKEDEV then?

Here is an example of virtual ethernet card (I know, that's not the right case but I could not find one applicable yet):
http://www.linux.it/~rubini/docs/vinter/vinter.html

Silly idea otherwise:
In order to shortcut DvdPlayer, can't we use something like tmp_infrared << /dev/venus_irrp END in the RcS
And then process tmp_infrared (this could delay remote orders, I guess?)

Cheers,
Matt

Hi,
thanks for the ideas.


NAME
MAKEDEV - create devices

SYNOPSIS
/sbin/MAKEDEV -V
/sbin/MAKEDEV [ -d directory ] [ -D directory ] [ -c configdir ] [ -m
maxdevices ] [-a] [-n] [-v] [-i] [-M] [-S] [-u] [-x] device ...

DESCRIPTION
MAKEDEV is a program that will create the devices in /dev used to
interface with drivers in the kernel.


It worth a try ... more reading then.





You mean to leave the following thing in execution:
tail -f /dev/venus_irrp > /tmp/infrared &

Could work ... But probably if the dvdplayer is more anger than the tail, will take commands form the ir
quicker that our tail ...
Probably we can think of like giving more execution privileges to the tail command,
¿¿ this is done using the nice command ... ?

Hi Vic,

Sorry to load you with these things.
An other way for pty could be "socat":
http://justcheckingonall.wordpress.com/2009/06/09/howto-vsp-socat/

The issue would then be to port it to the LG.

Cheers,
Matt

And even a new idea....:


brw-rw-rw- 2 bin bin 2, 60 Feb 12 10:45 fd0135ds18
brw-rw-rw- 1 bin bin 2, 16 Sep 15 16:13 fd0135ds21
brw-rw-rw- 2 bin bin 2, 44 Sep 15 16:13 fd0135ds36
brw-rw-rw- 3 bin bin 2, 36 Sep 15 16:13 fd0135ds9


A different kind of device would have a different major number. For example, here are the serial com ports:

crw-rw-rw- 1 bin bin 5,128 Feb 14 05:35 tty1A
crw-rw-rw- 1 root root 5, 0 Dec 9 13:13 tty1a
crw-rw-rw- 1 root sys 5,136 Nov 25 07:28 tty2A
crw-r--r-- 1 uucp sys 5, 8 Nov 25 07:16 tty2a


Notice that each of these files shares the "5" part of the pointer, but that the other number is different. The "5" means that the device is a serial port, and the other number tells exactly which com port you are referring to. In Unix parlance, the 5 is the "major number" and the other is the "minor number".

These numbers get created with a "mknod" command. For example, you could type "mknod /dev/myfloppy b 2 60" and then "/dev/myfloppy" would point to the same driver code that /dev/fd0135ds18 points to, and it would work exactly the same.


taken from: http://aplawrence.com/Unixart/devices.html

Pity, I am away from my LG right now ...

I was also beginning to look at mknod ^^

It seems that first step is to check the major/minor values for /dev/venus_irrp by issuing a

Código:

ls -l /dev

Then I guess the mknod is into the last version of the busybox Keltek provided? Just in case, I could see there were other busybox versions compiled for other RT based box. I presume these could also be used.

After creating a new device of right type, the first issue will then be to link them together with venus_irrp, no? And then to understand how to handle the data that goes by.

Anyway, you're doing great, again.

Cheers,
Matt

/dev$ls -l venus_irrp
crw------- 1 root root 234, 50 Jan 1 1970 venus_irrp


/dev # mknod /dev/my_ir c 234 50
/dev # ls
auth mem root urandom
cdrom0 misc rpc usb
console mtd scsi vc
discs mtdblock sda vcc
dvd my_ir sda1 venus_irrp
dvdvr null sda2 venus_vfd_keypad
full port sda3 venus_vfd_wrctl
i2c ptmx sda4 venus_vfdo
input pts se0 watch
kmem pty sg0 zero
kmsg random tts
loop rd tty




we have now our own device.
Unfortunaly, this is working exactly the same as the original.
so this is like a link.
that is, executing the key script, we can read 1 IR commands out of 10 aprox.
so, we are like in the same situation....

Lol ^^
Can't we then "delete" the venus_irrp?

Hi,
yes, I think so,
in fact, as the article comments this is a kind of backup.

as you might restore this at any time, with this magic numbers.

In fact, for example we can create exmaples like /dev/cdrom that is using using a human name links
for devices like /dev/sda3 for example.

What is next?
I do not know, probably I think I will play a bit the privileges of execution of process,
modifying it with the nice, renice commands.

vic1972 escribió:/dev$ls -l venus_irrp
crw------- 1 root root 234, 50 Jan 1 1970 venus_irrp


/dev # mknod /dev/my_ir c 234 50
/dev # ls
auth mem root urandom
cdrom0 misc rpc usb
console mtd scsi vc
discs mtdblock sda vcc
dvd my_ir sda1 venus_irrp
dvdvr null sda2 venus_vfd_keypad
full port sda3 venus_vfd_wrctl
i2c ptmx sda4 venus_vfdo
input pts se0 watch
kmem pty sg0 zero
kmsg random tts
loop rd tty




we have now our own device.
Unfortunaly, this is working exactly the same as the original.
so this is like a link.
that is, executing the key script, we can read 1 IR commands out of 10 aprox.
so, we are like in the same situation....

you can ask me, I try this some days before.
There can be an option to hack the process making the devices. But it is in kernel and I not have a working cross-compilation of kernel done yet.

Keltek, Victor,

I found a new link (I know, that's all I can do) with some very interesting stuff, I think.
Here it is:
http://www.cnitblog.com/gouzhuang/archive/2010/05/14/remote_control.html

Don't stop at the Chinese part (google traduction is working fine, by the way), I saw there was an english translation just after it.
There is some code there, and the guy managed to duplicate the IR driver at the kernel level.

I don't know whether it is immediately portable on the LG, probably not, I am not even sure it is developped on a very similar hardware or not, but this could give you some hints!!

Cheers,
Matt

PS: links are not in the english part, so here they are
driver source code: http://www.cnitblog.com/Files/gouzhuang/venus_ir_new.tar.zip
compiled kernel module: http://www.cnitblog.com/Files/gouzhuang/venus_ir_new.ko.zip

An other interesting Chinese link about a similar question:

http://www.hdpfans.com/viewthread.php?tid=847&extra=&page=1

One of guy writing in that thread is the author of the previous thread

This looks as the best way we should go. I'll try it.
Thanks a lot.

Hello friends,
more investigation,
I have just executed:

root@Venus:/tmp# nice -n -20 cat /dev/venus_irrp | hexdump
0000000 08f7 fd02 08f7 fd02 08f7 fd02 08f7 fd02


and i have been able to capture all the IR digits,
all and all
in fact DvdPlayer is not receiving the ir digits,
I know this is not usefull, but interesing how we are stoling the ir digits to dvdplayer jajaja
In fact, in the LG it is not even appear that red little icon telling the ir traffic.

Keltek escribió:This looks as the best way we should go. I'll try it.
Thanks a lot.

Little weird to answer to own message, but I must...
This kernel works = can be insmoded to kernel, but current kernel driver is not in form of module and I didn't see any way how to enable only this driver on boot.
There is I think only one solution - compile own kernel... I can try it, but I think it is little more difficult than compile own busybox or something similar.

wowwww
that sounds hell difficult

Indeed :-/

Victor, you will also find some interesting information in the second link for the script management of venus_irrp, with all the right parameters so that you don't miss pressed keys, etc. (as far as I understood), in case you want to manage all the "hexdump" output (and pipe it to the DvdPlayer process with the usual "letters" so that it works again as intended).

Sorry to have driven you on these hard steps. I'll try to find further info about implementation!

Cheers,
Matt

Thanks Matthelas,
how do you find such nice links !!!

YES, I think the second link will do it! I will test tonigh.
I am feeling like this is the final test (lets be optimistic)


Already translated by Google into English:
http://translate.google.com/translate?js=y&prev=_t&hl=es&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fwww.hdpfans.com%2Fviewthread.php%3Ftid%3D847%26extra%3D%26page%3D1&sl=zh-CN&tl=en

I have read the whole article and is the same as I described before - modify DvdPlayer and RootApp to use different device and pipe all to it

Keltek escribió:I have read the whole article and is the same as I described before - modify DvdPlayer and RootApp to use different device and pipe all to it

That's fully exact
The interest I found in that article is that it covers different ways of performing that piping and then give some hints about how to do it. I thought it could be useful to shorten your efforts (I am pretty aware you probably don't really need the information there ).

Cheers
Matt

Hi Keltek,

Would that help you:

gouzhuang escribió:Here's the code that does the trick:

--------- CODE BEGIN --------------

Código:

typedef void cleanup_fn (void);

static int __init venus_ir_new_init_module (void) (
int result;

struct device_driver * old_driver;
cleanup_fn * venus_ir_cleanup_module;

old_driver = driver_find ("VenusIR", & platform_bus_type);
if (old_driver) (
kobject_put (& old_driver-> kobj); / * decrease reference count * /
printk (KERN_DEBUG "Old VenusIR driver found at% p \ n", old_driver);

venus_ir_cleanup_module = (cleanup_fn *) kallsyms_lookup_name ("venus_ir_cleanup_module");
if (venus_ir_cleanup_module) (
printk (KERN_DEBUG "Found venus_ir_cleanup_module () @ 0x% p \ n", venus_ir_cleanup_module);
(* Venus_ir_cleanup_module) ();
printk (KERN_DEBUG "venus_ir_cleanup_module () called \ n");
) Else (
printk (KERN_WARNING "venus_ir_cleanup_module () not found! \ n");
return-ENOENT;
)
) Else (
printk (KERN_DEBUG "Old VenusIR driver NOT found, no need to clean up \ n");
)

/ * Module initialize code follows * /

...
---------- CODE END -------------------

In venus_ir_new_init_module (), I first use driver_find () to search the embedded driver by name, if found, then lookup its cleanup function venus_ir_cleanup_module () in kernel symbol table and call that function to let the old driver cleanup itself. After that, we can go on the normal initialization work.

Source: http://translate.google.fr/translate?u=http://www.cnitblog.com/gouzhuang/archive/2010/05/14/remote_control.html&sl=zh-CN&tl=en&hl=&ie=UTF-8

Se han reagrupado los códigos numéricos por rangos, para darles mas sentido, y que sean mas fáciles de recordar.



[Tienes que estar registrado y conectado para ver esa imagen]

Asi, tenemos:
90X AfterRecor.Poweroff
91X AutoPowerOff
92XXX Recover channel from inet (diifferent cities)
93X Custom scripts (carrusel, etc)
94X Backup/Restore channel file
95X Backup/Restore recording DB
99X actual version in lg/ install new version from inet

Y E S I T W O R K ! ! ! ! ! !

S I F U N C I O N A ! ! ! ! !

Ya tenemos acceso a los codigos IR, mediante la instalación en memoria de un nuevo modulo para el IR.
We have now direct acces to ir codes.
I have tried the key sheel script, and we are able to read complete ir codes, and dvdplayer keeps working normally,
all ir codes are intercepted ok.

this is a major milestone reached!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Thanks Matthelas, and Keltek.

As Keltek,
reported,

we need to download: download, unpack and copy in /usr/local/etc/kernel
this: http://www.cnitblog.com/Files/gouzhuang/venus_ir_new.ko.zip


Then we need to modify /usr/local/etc/rcS

# Load SATA driver
/sbin/modprobe sata_mars &

# Load alternative IRCD module
insmod /usr/local/etc/kernel/venus_ir_new.ko


and that's is all, once we reboot, a new device driver is ready for us!!!! /dev/shadow_irrp

Keltek, no need to say to please include this in the firmware pack thanks

Hi Vic,

That's great news!!
Don't you need to first unload the previous venus_irrp driver (is there no conflict? is it managed by loading that new driver early enough (and therefore have it on the flash partition?)?

Did you had a chance to test it and to check whether it's this driver that binds the hardware with DvdPlayer and RootApp, getting in parallel all the ir codes on shadow_irrp?

In particular, are "continuously pressed" keys working correctly (i.e volume up for example)?

That sounds really great, anyway!
Cheers,
Matt

Hello,
I think all the answer are YES

Of course I have now to re-program PipeManagement,
I do not know if will be in time for this version, or better to leave it for next version.... Let's see go it goes.


Yes, only insmod the module and that's it.
Now pressing the volume button, causes dvdplayer to move the volume bar, and also can be
read by sniffer program the shadow_irrp device.

Let's see now how it goes with the real use by PipeManagament.

As a summary, we had an issue detecting number pressed by users when playing a file.
Now, we will be able, hopefully, to implement the tricks:
4 : put in <<<<<<< directly
5: forward 5 minutes
6: put in >>>>>>> directly
3: forward 3 minutes
etc


We have also to remember that the last case of the windows pop-up when a record start, when playing a movie,
could not be done, because the event is transmitted with delays in the log of the application

That's so cool

vic1972 escribió:
We have also to remember that the last case of the windows pop-up when a record start, when playing a movie,
could not be done, because the event is transmitted with delays in the log of the application

Indeed, but we can propose some workaround
For example: when "playing" a movie (we'll have to remember what was the sequence of IR Codes to launch that movie), if you push on a specific button when there is a pop up, then a "macro" will be activated that does:
1- OK
2- relaunch the movie (same sequence of codes that were initially set, minus everything related to volume, etc.)
3- OK again (to "continue" the reading of the movie where you previously stopped)

Then, when you get the popup, instead of pushing OK you push an other button (or you can push OK, it can be automatically followed by 2 & 3), and you will be back to your movie in a eyeblink

Thanks a lot for all the work you both are doing!

Cheers,
Matt