Hello. Can someone send a notification to the admin of linuxtv.org. I'm not receiving any of those MLs but it would be great if the web archive would be up & running again. The web MLs are down and the webmaster@linuxtv dot org doesn't seem to answer.
XSLException Type is : XSLTProcessorException Message is : Could not parse /var/www/htdocs/linuxtv.org/mailinglists.xml/vdr/ document!
ZitatOriginally posted by thauta
Hello, sorry if this is a faq but I cant seem to find the answer. After upgrading to 0.5.0 the keymap changed so that there's nomore VDRButtonRed = ... etc in my .xine/keymap. Instead there's some vdr-stuff atleast in xine-ui's actions.h. So as a result I can't anymore control vdr from the keyboard (change channels, select red,green etc), only the menucommands (from KP) work.
Hmm, I played a bit with xine-ui's source and added #define ENABLE_VDR_KEYS to actions.[ch] and kbindings.[ch]. That fixed the problem.
What is the proper method for doing this defining, an option in the Makefile or?
Tomi
Hello, sorry if this is a faq but I cant seem to find the answer. After upgrading to 0.5.0 the keymap changed so that there's nomore VDRButtonRed = ... etc in my .xine/keymap. Instead there's some vdr-stuff atleast in xine-ui's actions.h. So as a result I can't anymore control vdr from the keyboard (change channels, select red,green etc), only the menucommands (from KP) work.
I tried copying the old keymap back to it's place but it keeps getting over-written by xine. Any hints on this one?
Another thing is what version of xine this vdr-xine-0.5.0 is against? I'm asking because the patches included won't apply cleanly to current cvs or to the cvs-20040826230000. Looks like some stuff is already in xine-ui so a patch wont be needed?
Against cvs-20040826230000:
[13:18:39] (a) #patch -d. -p0 < ../VDR/PLUGINS/src/xine/patches/xine-lib.patch
patching file xine-lib/configure.ac
Hunk #1 succeeded at 2048 (offset -51 lines).
Hunk #3 succeeded at 2252 (offset -51 lines).
patching file xine-lib/include/xine.h.in
patching file xine-lib/src/Makefile.am
patching file xine-lib/src/vdr/Makefile.am
patching file xine-lib/src/vdr/input/Makefile.am
patching file xine-lib/src/vdr/input/input_vdr.c
patching file xine-lib/src/vdr/input/input_vdr.h
patching file xine-lib/src/vdr/post/Makefile.am
patching file xine-lib/src/vdr/post/post_vdr.c
patching file xine-lib/src/vdr/post/post_vdr.h
[13:19:52] (a) #patch -d. -p0 < ../VDR/PLUGINS/src/xine/patches/xine-ui.patch
patching file xine-ui/src/fb/actions.c
Hunk #1 FAILED at 210.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/fb/actions.c.rej
patching file xine-ui/src/fb/actions.h
Hunk #1 FAILED at 154.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/fb/actions.h.rej
patching file xine-ui/src/xitk/kbindings.c
Hunk #1 FAILED at 438.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/xitk/kbindings.c.rej
patching file xine-ui/src/xitk/kbindings.h
Hunk #1 FAILED at 171.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/xitk/kbindings.h.rej
And against todays cvs:
[13:28:33] (a) #patch -d. -p0 < ../VDR/PLUGINS/src/xine/patches/xine-lib.patch
patching file xine-lib/configure.ac
Hunk #1 FAILED at 2099.
Hunk #2 succeeded at 2158 (offset 2 lines).
1 out of 3 hunks FAILED -- saving rejects to file xine-lib/configure.ac.rej
patching file xine-lib/include/xine.h.in
Hunk #1 succeeded at 1463 (offset 6 lines).
patching file xine-lib/src/Makefile.am
Hunk #1 succeeded at 28 (offset 1 line).
patching file xine-lib/src/vdr/Makefile.am
patching file xine-lib/src/vdr/input/Makefile.am
patching file xine-lib/src/vdr/input/input_vdr.c
patching file xine-lib/src/vdr/input/input_vdr.h
patching file xine-lib/src/vdr/post/Makefile.am
patching file xine-lib/src/vdr/post/post_vdr.c
patching file xine-lib/src/vdr/post/post_vdr.h
[13:29:58] (a) #patch -d. -p0 < ../VDR/PLUGINS/src/xine/patches/xine-ui.patch
patching file xine-ui/src/fb/actions.c
Hunk #1 FAILED at 210.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/fb/actions.c.rej
patching file xine-ui/src/fb/actions.h
Hunk #1 FAILED at 154.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/fb/actions.h.rej
patching file xine-ui/src/xitk/kbindings.c
Hunk #1 FAILED at 438.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/xitk/kbindings.c.rej
patching file xine-ui/src/xitk/kbindings.h
Hunk #1 FAILED at 171.
1 out of 1 hunk FAILED -- saving rejects to file xine-ui/src/xitk/kbindings.h.rej
Thanks, Tomi
ZitatOriginally posted by stl
When output format is set to YUY2 I was able to view softdevice DFB-output
on my TV via my matrox G400. Connection was via an RGB-Scart cable from
primary head.
Hello. I have also a G400 and I'm trying to get the picture to my TV from the second head with softdevice. The cable used is a rgb-scart which works when used with mplayer -vo dfbmga. Here's my directfbrc:
matrox-crtc2
matrox-tv-standard=pal
matrox-cable-type=scart-rgb
primary-layer=2
vt-switch
vt-switching
sync
mode=720x576
depth=16
pixelformat=YUY2
#disable-module=keyboard
disable-module=joystick
disable-module=lirc
disable-module=mouse
disable-module=ps2mouse
disable-module=serialmouse
disable-module=sonypi
Stefan, can you please post here your own directfbrc so we can compare if there's something wrong with my config? I have also tried with pixelformat=ARGB and many others but no luck =(
Here's the log:
http://www.ee.oulu.fi/~thautako/dfblog
DirectFB, DFB++, FusionSound are from todays cvs. Has anyone a running system or does the support for the second head need more coding? I can give debug information if needed. =)
Tomi (Finland)
