Hi! I have an EPIA M motherboard and a Nexus-s FF DVB-s card. What kind of VDR/plugins implementation do you recommend to me? I have planned to use the svga out from the nexus and the onboard EPIA RCA to the 6 channel audio output. What mpeg2 hardware decoder you recommend to use? The nexus mpeg2 decoder included in the dvb-s pci card or the mpeg2 decoder included in the CLE266 chipset? In the last option I have to use the softdevice plugin? Can I turn the FF card and use a cheaper budget card with the CLE266 hw mpeg decoder with the same quality? Witch combination do you think is better? To many questions are unanswered in my head. Sorry about it and thanks for your help.
Leo Márquez schrieb:
Hi! I have an EPIA M motherboard and a Nexus-s FF DVB-s card. What kind of VDR/plugins implementation do you recommend to me?
The Epia will be too slow to play MPEG4 I bet. So you don't have to bother with the MPlayer-Plugin. But you can have anything else, like DVD, VCD, Image, MP3 etc.
I have planned to use the svga out from the nexus
You mean the chinch video out on the Nexus. and the onboard EPIA
RCA to the 6 channel audio output.
I guess you'll have to use the bitstreamout plugin for that.
What mpeg2 hardware decoder you recommend to use? The nexus mpeg2 decoder included in the dvb-s pci card or the mpeg2 decoder included in the CLE266 chipset?
Definitely the Nexus's mpeg2 decoder.
In the last option I have to use the softdevice plugin?
No, just use the Nexus's mpeg2 decoder
Can I turn the FF card and use a cheaper budget card with the CLE266 hw mpeg decoder with the same quality?
Possible, but hard to set up. Don't bother with it in the beginning. DON'T!
Witch combination do you think is better? To many questions are unanswered in my head. Sorry about it and thanks for your help.
Cheers
Sebastian
Leo Márquez a écrit :
Hi! I have an EPIA M motherboard and a Nexus-s FF DVB-s card. What kind of VDR/plugins implementation do you recommend to me? I have planned to use the svga out from the nexus and the onboard EPIA RCA to the 6 channel audio output.
You will either use the HW MPEG2 decoder of the FF-card, or the one on the EPIA, or a software decoder : * FF HW decoder : use the TV-out connector of the DVB card, you will get video quality (interlaced, s-video signal or RGB signal if you have the connector). No required plugin (plain VDR is aimed at this configuration : no surprise) * CLE266 HW decoder or software decoder : you will need a plugin (softdevice or vdr-xine or xineliboutput), video output through the VGA connector (high quality, suitable for LCD TVs) or the s-video-out of the mobo (bad to acceptable quality, depending on details : I can comment more on this, or search the ML archive). You could have bought a budget card if you plan to use this setup.
vdr-xine or xineliboutput will use the hardware decoder if you use the right X, XvMC, etc. Aim at really recent version or CVS for all that stuff. I can provide links for Debian repositories if you use that distro (or search the list archive : it's a FAQ). softdevice won't use the CLE266 for now, but this might be on the TODO. If you have a Nehemiah 1Ghz, software decoding is not an issue (30% to 70% CPU, depending on the stream).
Sound : * FF HW decoder : I don't really know, but the FF card can output SPDIF with the right connector, or you can use the bitstreamout plugin to use the mobo's sound card/connector. * softdevice : AC/3 output is on the TODO, might be out soon * vdr-xine / xineliboutput : might work as-is (depends on Xine and it's config, didn't test)
What mpeg2 hardware decoder you recommend to use? The nexus mpeg2 decoder included in the dvb-s pci card or the mpeg2 decoder included in the CLE266 chipset?
I'd definitely recommend CLE266 / software decoding. The details depend on your hardware setup : use Xine if you have or need X (either vdr-xine or xineliboutput), which nearly requires a keyboard/mouse. Use softdevice if you want a real set-top-box (no keyboard or mouse, just the remote). Using the VGA-out of the mobo will give you full resolutions on LCD TV, even s-video out could be perfect in the next months.
In the last option I have to use the softdevice plugin? Can I turn the FF card and use a cheaper budget card with the CLE266 hw mpeg decoder with the same quality? Witch combination do you think is better?
I personnaly use lastest VDR + softdevice, which requires compiling/packaging skills. This is definately rewarding. The simplest way is to use the FF HW decoder. If you want to use the most hardware of you mobo, without compiling, go for vdr-xine or xineliboutput. * vdr-xine : the plugin provides a socket through which a regular Xine conn connect and get the VDR output. There is recent network support (VDR on the server, Xine on a remote client). Problems can arise because you have two processes to manage (client + server), not counting the whole X) * xineliboutput : the author didn't announce it on this ML (lastest version is quite recent). Directly link libxine in the VDR binary, thus no client/server problem, but still the whole Xine functionnality, and requires X.
To many questions are unanswered in my head. Sorry about it and thanks for your help.
You can still ask : the list is here for that.
Sebastian a écrit :
Leo Márquez schrieb:
Hi! I have an EPIA M motherboard and a Nexus-s FF DVB-s card. What kind of VDR/plugins implementation do you recommend to me?
The Epia will be too slow to play MPEG4 I bet. So you don't have to bother with the MPlayer-Plugin. But you can have anything else, like DVD, VCD, Image, MP3 etc.
EPIA *might* be too slow to transcode MPEG4 to MPEG1/2 for the Nexus (that's how the mplayer-plugin work). It won't be too slow for direct MPEGS4 decoding using a sogftware decoder and direct output through the VGA card (see the softplay plugin used with softdevice, or the xine-player script used with vdr-xine). This can influence your decision.
What mpeg2 hardware decoder you recommend to use? The nexus mpeg2 decoder included in the dvb-s pci card or the mpeg2 decoder included in the CLE266 chipset?
Definitely the Nexus's mpeg2 decoder.
Advice definitely differ ! (see my previous post)
Can I turn the FF card and use a cheaper budget card with the CLE266 hw mpeg decoder with the same quality?
Possible, but hard to set up. Don't bother with it in the beginning. DON'T!
One thing we agree upon : software decoding is hard to setup. Out-of-the-box VDR is definitely based on FF-card. On the other hand, software decoding has really matured since a year. Decide if you can spend enough time to setup software decoding, and be rewarded for you hard work, or just plug-and-play and have no fun ;-)
Thanks Nicolas and Sebastian for your answers. I notice that is a polemic question (2 answers, 2 different opinions ;-) ) I have already build and VDR in a common PC compiling it from source code. I am arranged to spend time setting up my VDR if I obtain the thing I need taking the best advantage of my hw. I don't have a LCD monitor but in the future it's probably. I use debian but I think I don't need X. I want my VDR to see and record TV, play mpeg4 movies, dvd, mp3 and I will try to play with emulators like MAME, Xbox, etc. Do you think I need X? Is needed for software decoding? Can I use the mobo HW decoder to play dvd's and soft decoder to play mpeg4?
Thanks again
En/na Nicolas Huillard ha escrit:
Sebastian a écrit :
Leo Márquez schrieb:
Hi! I have an EPIA M motherboard and a Nexus-s FF DVB-s card. What kind of VDR/plugins implementation do you recommend to me?
The Epia will be too slow to play MPEG4 I bet. So you don't have to bother with the MPlayer-Plugin. But you can have anything else, like DVD, VCD, Image, MP3 etc.
EPIA *might* be too slow to transcode MPEG4 to MPEG1/2 for the Nexus (that's how the mplayer-plugin work). It won't be too slow for direct MPEGS4 decoding using a sogftware decoder and direct output through the VGA card (see the softplay plugin used with softdevice, or the xine-player script used with vdr-xine). This can influence your decision.
What mpeg2 hardware decoder you recommend to use? The nexus mpeg2 decoder included in the dvb-s pci card or the mpeg2 decoder included in the CLE266 chipset?
Definitely the Nexus's mpeg2 decoder.
Advice definitely differ ! (see my previous post)
Can I turn the FF card and use a cheaper budget card with the CLE266 hw mpeg decoder with the same quality?
Possible, but hard to set up. Don't bother with it in the beginning. DON'T!
One thing we agree upon : software decoding is hard to setup. Out-of-the-box VDR is definitely based on FF-card. On the other hand, software decoding has really matured since a year. Decide if you can spend enough time to setup software decoding, and be rewarded for you hard work, or just plug-and-play and have no fun ;-)
On Wed, 18 May 2005 11:27:14 +0200, in boerde.lists.vdr you wrote:
The Epia will be too slow to play MPEG4 I bet. So you don't have to bother with the MPlayer-Plugin. But you can have anything else, like DVD, VCD, Image, MP3 etc.
The Epia (at least my ME6000) is fast enough for most MPEG4. It plays most DivX in reasonable quality and my holiday-videos in perfect quality. CPU-usage is just around 20% for the latter.
Playing DVD with DVD-Plugin is OK as well.
Christian
Leo Márquez a écrit :
Thanks Nicolas and Sebastian for your answers. I notice that is a polemic question (2 answers, 2 different opinions ;-) ) I have already build and VDR in a common PC compiling it from source code. I am arranged to spend time setting up my VDR if I obtain the thing I need taking the best advantage of my hw. I don't have a LCD monitor but in the future it's probably.
So you're ready for the software decoding (ie. no FF DVB card) ! Welcome on board.
I use debian but I think I don't need X. I want my VDR to see and record TV, play mpeg4 movies, dvd, mp3 and I will try to play with emulators like MAME, Xbox, etc. Do you think I need X? Is needed for software decoding?
X + Xine = HW decoding using the CLE266. Xine without X won't do it. Softdevice won't do it right now. Without X, you can use softdevice on DirectFB (softdevice has a choice of 4 output methods : plain frame-buffer (slow), vidix (need root access), DirectFB and X/Xv. The last 3 will use accelerated video support (blit, colorspace conversion, scaling). DirectFB also supports transparent OSD with no CPU load (don't know for the others). If you plan to use softdevice, subscribe to the softdevice-devel@berlios.de ML. I don't know if MAME/XBox make use of DirectFB, and if they will integrate well with VDR (fight for the output, or transparent playground over live video !). DirectFB has support for windowing through XDirectFB, if you're brave enough (I'm not).
Can I use the mobo HW decoder to play dvd's and soft decoder to play mpeg4?
I you use Xine on X, yes. This implies vdr-xine or xineliboutput.
En/na Nicolas Huillard ha escrit:
Leo Márquez a écrit :
Thanks Nicolas and Sebastian for your answers. I notice that is a polemic question (2 answers, 2 different opinions ;-) ) I have already build and VDR in a common PC compiling it from source code. I am arranged to spend time setting up my VDR if I obtain the thing I need taking the best advantage of my hw. I don't have a LCD monitor but in the future it's probably.
So you're ready for the software decoding (ie. no FF DVB card) ! Welcome on board.
Thanks!
I use debian but I think I don't need X. I want my VDR to see and record TV, play mpeg4 movies, dvd, mp3 and I will try to play with emulators like MAME, Xbox, etc. Do you think I need X? Is needed for software decoding?
X + Xine = HW decoding using the CLE266. Xine without X won't do it. Softdevice won't do it right now. Without X, you can use softdevice on DirectFB (softdevice has a choice of 4 output methods : plain frame-buffer (slow), vidix (need root access), DirectFB and X/Xv. The last 3 will use accelerated video support (blit, colorspace conversion, scaling). DirectFB also supports transparent OSD with no CPU load (don't know for the others). If you plan to use softdevice, subscribe to the softdevice-devel@berlios.de ML. I don't know if MAME/XBox make use of DirectFB, and if they will integrate well with VDR (fight for the output, or transparent playground over live video !). DirectFB has support for windowing through XDirectFB, if you're brave enough (I'm not).
I'm receiving a lot of new information! thanks. I try to understand it considering my english level is not high. I'm between: - X + Xine But I'm afraid about performance with running X. What desktop you recommend? windowmaker? Any ideas to take advantge from X aside from Xine?
- Softdevice + DirectFB (unichrome for hw acceleration?)
Can I use the mobo HW decoder to play dvd's and soft decoder to play mpeg4?
I you use Xine on X, yes. This implies vdr-xine or xineliboutput.
What are the difs on this plugins? Thanks
Hi again,
Without X, you can use softdevice on DirectFB (softdevice has a choice of 4 output methods : plain frame-buffer (slow), vidix (need root access), DirectFB and X/Xv.
Vidix is this? (from vdr wiki): · Quasi hardware decoding through XvMC (/*XV*ideo *M*otion *C*ompensation/) with low CPU load This is supported with some NVidia graphics cards (GF4MX400 sowie >= GF5), S3 Unicrome (VIA Epia Boards) and possibly other. (Option /XvMC/ in *XF86config*)
Or this?:
* Software decoding. With overlay output via Xv (/*XV*ideo/).
Works with all graphic cars (Option /v4l/ in *XF86config*)
I've put Nicolas initial reply into the vdr wiki.
http://www.linuxtv.org/vdrwiki/index.php/Software-playback-epia
On Wed, 2005-05-18 at 12:53 +0200, Leo Márquez wrote:
Hi again,
Without X, you can use softdevice on DirectFB (softdevice has a choice of 4 output methods : plain frame-buffer (slow), vidix (need root access), DirectFB and X/Xv.
Vidix is this? (from vdr wiki): · Quasi hardware decoding through XvMC (/*XV*ideo *M*otion *C*ompensation/) with low CPU load
vidix is not XvMC. vidix is a library for direct access to the graphics hardware's overlay buffer. It allows writing pixelvalues directly, avoiding any X server or console fb api interaction. The graphics hardware will do scaling and colour space conversion.
XvMC is an X11 extension, so requires an X server. I think there are libraries to do this without an X server when using epia hardware, but I am not familiar with it.
Or this?:
* Software decoding.
Yes.
With overlay output via Xv (/*XV*ideo/).
Works with all graphic cars (Option /v4l/ in *XF86config*)
vidix can be used with either a framebuffer setup (kernel module), or with X11. This is because vidix itself doesn't know how to set up refresh rates and other parameters to get the graphics card running. It only knows how and where to push pixels. And it has nothing to do with v4l or XVideo.
On Wed, 2005-05-18 at 11:38 +0200, Nicolas Huillard wrote:
{snippage}
I'd definitely recommend CLE266 / software decoding. The details depend on your hardware setup : use Xine if you have or need X (either vdr-xine or xineliboutput), which nearly requires a keyboard/mouse. Use softdevice if you want a real set-top-box (no keyboard or mouse, just the remote). Using the VGA-out of the mobo will give you full resolutions on LCD TV, even s-video out could be perfect in the next months.
I'm currently setting up and testing an Epia MII13000 system using the xine plugin and the S-Video output. The quality of this is now quite good as long as you use a new version of the Unichrome driver which supports the 720x576Noscale modes (for PAL, at least: I think there are equivalent modes for NTSC).
I personnaly use lastest VDR + softdevice, which requires compiling/packaging skills. This is definately rewarding. The simplest way is to use the FF HW decoder. If you want to use the most hardware of you mobo, without compiling, go for vdr-xine or xineliboutput.
- vdr-xine : the plugin provides a socket through which a regular Xine
conn connect and get the VDR output. There is recent network support (VDR on the server, Xine on a remote client). Problems can arise because you have two processes to manage (client + server), not counting the whole X)
- xineliboutput : the author didn't announce it on this ML (lastest
version is quite recent). Directly link libxine in the VDR binary, thus no client/server problem, but still the whole Xine functionnality, and requires X.
With the above setup, I am seeing a CPU load of ca. 1-2% for X itself and anything from 6-35% for xine. I have yet to sort out what is causing the range of CPU loads: other people have mentioned a figure of ca. 15% if hardware decoding is working properly.
I am starting X using 'startx' with a very minimal .xinitrc which just runs xine in a loop with the desired options.
If you already have a full-featured card, you can try the output from each and see which works best.
Cheers,
Laz
Laurence Abbott a écrit :
On Wed, 2005-05-18 at 11:38 +0200, Nicolas Huillard wrote:
{snippage}
I'd definitely recommend CLE266 / software decoding. The details depend on your hardware setup : use Xine if you have or need X (either vdr-xine or xineliboutput), which nearly requires a keyboard/mouse. Use softdevice if you want a real set-top-box (no keyboard or mouse, just the remote). Using the VGA-out of the mobo will give you full resolutions on LCD TV, even s-video out could be perfect in the next months.
I'm currently setting up and testing an Epia MII13000 system using the xine plugin and the S-Video output. The quality of this is now quite good as long as you use a new version of the Unichrome driver which supports the 720x576Noscale modes (for PAL, at least: I think there are equivalent modes for NTSC).
I plan to merge that mode back to the frame-buffer driver. Are you really happy with this it ? I think this mode is still in the unichrome CVS repository (ie. not released yet).
...
I am starting X using 'startx' with a very minimal .xinitrc which just runs xine in a loop with the desired options.
That's what I did, except for the loop (to facilitate stop) :
~vdr/.xinitrc ----------- xine -L --fullscreen --geometry 720x576 --borderless --hide-gui --no-logo --no-splash vdr://tmp/vdr-xine/stream#demux:mpeg_pes -----------
Leo Márquez a écrit :
I'm receiving a lot of new information! thanks. I try to understand it considering my english level is not high. I'm between: - X + Xine But I'm afraid about performance with running X. What desktop you recommend? windowmaker?
No desktop. See Laurence Abbott's reply. No performance impact, except that X in memory hungry, and Xine also. 256MB for VDR + Xine + X is a minimum (with a little swapping). 128MB is enough for VDR + softdevice (128MB more for disk cache is marvelous)
Any ideas to take advantge from X aside from Xine?
I think that a VDR box must remain an easy to use, always ready comodity, so nothing else must be there. Thus no other use for X...
- Softdevice + DirectFB (unichrome for hw acceleration?)
HW acceleration in this case is only Xv-equivalent, not XvMC.
I you use Xine on X, yes. This implies vdr-xine or xineliboutput.
What are the difs on this plugins?
See previous posts. Since I didn't use xineliboutput, I can't really say for it. What I understand is that xineliboutput is between vdr-xine and softdevice : it uses libxine like vdr-xine (ie. all the codecs, processing steps, output methods of xine), but links to vdr like softdevice (ie. single process, low memory footprint).
On Wed, 2005-05-18 at 14:18 +0200, Nicolas Huillard wrote:
Laurence Abbott a écrit :
I'm currently setting up and testing an Epia MII13000 system using the xine plugin and the S-Video output. The quality of this is now quite good as long as you use a new version of the Unichrome driver which supports the 720x576Noscale modes (for PAL, at least: I think there are equivalent modes for NTSC).
I plan to merge that mode back to the frame-buffer driver. Are you really happy with this it ?
It is a marked improvement over the overscan modes and something like 800x600. When I first got the board, the output was really bad. I eventually found it was because it was running at 1024x768 (rather than the 720x576 I'd asked for) and this was being scaled to 720x576 by the encoder chip giving a really nasty flickery and blurry image.
I think this mode is still in the unichrome CVS repository (ie. not released yet).
It's an Epia MII that I've got which has the VT1622a rather than the VT122 encoder chip and the Noscale mode wasn't available for it until I hacked one together.
What is the current status of softdevice / frambuffer / HW acceleration for the CLE266 chipset? Are there any up-to-date HOWTOs for this? I looked into this a couple of months back and there seemed to be a lot of conflicting information! Is it now simply a case of installing DirectFB and setting permissions on /dev/fb/0, or whatever? What kernel modules are needed, and are they they stock kernel via framebuffer driver, or do I need a CVS checkout for that?
I was trying to get softdevice to work under Gentoo which was a complete nightmare. Changed to Debian and things were much easier, although I had moved onto the X / xine method by then.
I'm only running X at the moment because I got that to work! I have no other need for it on that box.
;)
Cheers,
Laz
Hi,
The EPIA M -> does not need a full featured card. If you have one make sure you have the right power supply (it will use more current than a budget card I think).
My machine is work during day, TV in the evening and PVR when I'm not there/in bed so it runs X. Right now I don't have hardware MPEG2 because I'm playing with FC4 and the Fedora kernel does not get along with unichrome DRM (guess who's fault that is...). With MPEG2 acceleration (M10000N) the difference is 65€ budget card vs. 200€ FF - performance wise there is no difference. Now if you need CI that is another story.
Tony
Laurence Abbott a écrit :
On Wed, 2005-05-18 at 14:18 +0200, Nicolas Huillard wrote:
Laurence Abbott a écrit :
...
supports the 720x576Noscale modes (for PAL, at least: I think there are
...
I think this mode is still in the unichrome CVS repository (ie. not released yet).
It's an Epia MII that I've got which has the VT1622a rather than the VT122 encoder chip and the Noscale mode wasn't available for it until I hacked one together.
What method, documents, etc. did you use to get that mode working ? I had a mail exchange with the unichrome maintainer who added the 720x576Noscale mode to CVS, but he uses tools that do not work with the frame-buffer driver. Whatever tiny information would help me. I plan to check what differences exist between the scaled and noscale modes in the X driver, and merge them back into the frame-buffer driver. That process will certainly exhaust my patience and time very quickly, but I think it's worth to try.
What is the current status of softdevice / frambuffer / HW acceleration for the CLE266 chipset? Are there any up-to-date HOWTOs for this? I looked into this a couple of months back and there seemed to be a lot of conflicting information! Is it now simply a case of installing DirectFB and setting permissions on /dev/fb/0, or whatever? What kernel modules are needed, and are they they stock kernel via framebuffer driver, or do I need a CVS checkout for that?
I'm in the process to cleaning things up in my setup (the goal being proper Debian packages for softdevice plugin). Things are not quite clear right now, but the summary would be like : * use standard kernel * add the viafb frame-buffer driver from http://patcher2k.012webpages.com/ * compile viafb as a module, but no vesafb or cle266vgaio (IIRC) * /etc/directfbrc and /etc/fb.modes have to be cleaned up * get DirectFB, DFB++, FFmpeg, et al. from CVS (older version might work) * compile softdevice and enjoy ! Little problems I still have are related to /etc/directfbrc.
I was trying to get softdevice to work under Gentoo which was a complete nightmare. Changed to Debian and things were much easier, although I had moved onto the X / xine method by then.
If you wait long enough, I could provide working packages for Debian through Tobias Grimm's official Debian repository...
I'm only running X at the moment because I got that to work! I have no other need for it on that box.
I took the time make have softdevice working, and I'm really pleased of it. Join the softdevice-devel ML on BerliOS if you're interested.
Hi again!
Seems like many people actually like using an EPIA with a budget card. What I would like to know is what possibilities are there to connect to a TV set? I mean the Epia just features a simple fbas tv-out, right? So that's a downside, because with a J2 pinblock on a FF card you can use RGB or S-Video instead of FBAS. Or am I missing anything?
Thanks
Sebastian
Sebastian a écrit :
Seems like many people actually like using an EPIA with a budget card. What I would like to know is what possibilities are there to connect to a TV set? I mean the Epia just features a simple fbas tv-out, right? So that's a downside, because with a J2 pinblock on a FF card you can use RGB or S-Video instead of FBAS. Or am I missing anything?
EPIA M also have a s-video connector. Maybe you are refering to older EPIAs without this conneector. Better quality is achieved using the VGA connector to a LCD/plasma TV. And I mean really better quality. Tony Grant could explain more on this. You can also directly use your average CRT monitor, which is already far better than any TV.
Le mercredi 18 mai 2005 à 19:49 +0200, Nicolas Huillard a écrit :
Better quality is achieved using the VGA connector to a LCD/plasma TV. And I mean really better quality. Tony Grant could explain more on this. You can also directly use your average CRT monitor, which is already far better than any TV.
What kind of TV do you have?
If it is flat and has SVGA/DVI you have a winner. Use that, forget SCART, svideo and composite.
I think that the only way to get a good picture out of the EPIA would be to use a transcoder attached to the VGA out. I sold my transcoder last year (yes I am kicking myself now) so I can't test.
Cheers
Tony
On Wednesday 18 May 2005 18:27, Nicolas Huillard wrote:
Laurence Abbott a écrit :
It's an Epia MII that I've got which has the VT1622a rather than the VT122 encoder chip and the Noscale mode wasn't available for it until I hacked one together.
What method, documents, etc. did you use to get that mode working ? I had a mail exchange with the unichrome maintainer who added the 720x576Noscale mode to CVS, but he uses tools that do not work with the frame-buffer driver. Whatever tiny information would help me.
The unichrome drivers currently use modes from a table, rather than being created on-the-fly due to a lack of info from Via. The 720x576Noscale mode for the VT1622, i.e. Epia M series and others, was written by Terry Barnaby and submitted to the unichrome-users mailing list. With some pointers from him and a bit of prodding-registers-whilst-watching-the-picture, I created a similar patch for the VT1622a found in the Epia MII that I have and he didn't. This was a few weeks back and I don't know if any of the patches have made it into the proper CVS tree or not. The structure of the mode table changed somewhere along the line, too, which added to the fun!
I plan to check what differences exist between the scaled and noscale modes in the X driver, and merge them back into the frame-buffer driver. That process will certainly exhaust my patience and time very quickly, but I think it's worth to try.
What is the DirectFB driver like? Is that using tables similarly? (I've just grabbed the latest DirectB but have yet to look at it.) I can forward a copy of the patches on to you (or this list) if you like. What modes can DirectFB do currently? I see that there is a unichrome driver and a cle266 driver: which one do I want?
What is the current status of softdevice / frambuffer / HW acceleration for the CLE266 chipset? Are there any up-to-date HOWTOs for this? I looked into this a couple of months back and there seemed to be a lot of conflicting information! Is it now simply a case of installing DirectFB and setting permissions on /dev/fb/0, or whatever? What kernel modules are needed, and are they they stock kernel via framebuffer driver, or do I need a CVS checkout for that?
I'm in the process to cleaning things up in my setup (the goal being proper Debian packages for softdevice plugin). Things are not quite clear right now, but the summary would be like :
- use standard kernel
- add the viafb frame-buffer driver from http://patcher2k.012webpages.com/
- compile viafb as a module, but no vesafb or cle266vgaio (IIRC)
- /etc/directfbrc and /etc/fb.modes have to be cleaned up
- get DirectFB, DFB++, FFmpeg, et al. from CVS (older version might work)
- compile softdevice and enjoy !
Little problems I still have are related to /etc/directfbrc.
I'll give it a go... Debian currently doesn't have DFB++ packages, or not that I've found.
I was trying to get softdevice to work under Gentoo which was a complete nightmare. Changed to Debian and things were much easier, although I had moved onto the X / xine method by then.
If you wait long enough, I could provide working packages for Debian through Tobias Grimm's official Debian repository...
Sounds good but I may have had a bit of a play by then!
;)
I'm only running X at the moment because I got that to work! I have no other need for it on that box.
I took the time make have softdevice working, and I'm really pleased of it. Join the softdevice-devel ML on BerliOS if you're interested.
I may just do that. How well does the softdevice plugin handle things like AFD modes which need expanding and cropping, etc.?
Cheers,
Laz
On Mittwoch, 18. Mai 2005 20:34, Laz wrote:
I may just do that. How well does the softdevice plugin handle things like AFD modes which need expanding and cropping, etc.?
To my opinion they are supported. Well some others still have some whishes on selecting various aspect ratios. Yes there are some TODOs if your TV is driven via SVGA connector and expects a native resolution of 1024x1024 pixels to be of aspect 16:9 .
Hi Tony,
If it is flat and has SVGA/DVI you have a winner. Use that, forget SCART, svideo and composite.
My TV is flat and has DVI.
I think that the only way to get a good picture out of the EPIA would be to use a transcoder attached to the VGA out. I sold my transcoder last year (yes I am kicking myself now) so I can't test.
What is a "Transcoder"?
My TV has a VGA in, too. Would the quality with DVI and a Transcoder be better than that?
TIA, Michael
tony schrieb:
Le mercredi 18 mai 2005 à 19:49 +0200, Nicolas Huillard a écrit :
Better quality is achieved using the VGA connector to a LCD/plasma TV. And I mean really better quality. Tony Grant could explain more on this. You can also directly use your average CRT monitor, which is already far better than any TV.
What kind of TV do you have?
If it is flat and has SVGA/DVI you have a winner. Use that, forget SCART, svideo and composite.
I think that the only way to get a good picture out of the EPIA would be to use a transcoder attached to the VGA out. I sold my transcoder last year (yes I am kicking myself now) so I can't test.
Cheers
Tony
Hi Tony,
I got a good old fashioned TV :) And that's not going to change for a while, because I'm not interested in HDTV too much yet. I'm ok with DVB/DVD. And for that matter I find a TV better than something else (-> interlaced material).
Cheers
Sebastian
Le mercredi 18 mai 2005 à 22:10 +0200, Michael Reinelt a écrit :
What is a "Transcoder"?
It does the same thing as the VIA TV out chipset, converts computer signal to TV signal. If you have a high end one it will be better than the onboard stuff (it will also cost a lot).
My TV has a VGA in, too.
OK cool just use the VGA, that will give you the best picture and at no extra cost! Yay!
Tony
Le mercredi 18 mai 2005 à 23:09 +0200, Sebastian a écrit :
I got a good old fashioned TV :) And that's not going to change for a while, because I'm not interested in HDTV too much yet. I'm ok with DVB/DVD. And for that matter I find a TV better than something else (-> interlaced material).
I have not used a TV in years but watch on Samsung TFT with VGA in and composite (scart) in:
- analog hertzien (what can I say... yuck...) - analog sat (fuzzy picture) - DVB-S - DVD
There is a huge difference between the image quality of DVB-S stations - France Television sends out a tiny stream at 5xx x 5xx pixels whereas the BBC sends at 7xx x 5xx pixels.
There is a huge difference in quality between programs.
I do not have any issues with interlacing (maybe because my screen is small) on digital signals. Some programs have a lot of artifacts on diagonals and / or fast moving scenes.
I am using xine with deinterlacing turned off. Tried with it on and didn't see any difference.
Cheers
Tony
# dvbscan Hotbird-13.0E -v >/tmp/channels.conf
scanning Hotbird-13.0E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 12539000 H 27500000 3
tune to: 12539:h:0:27500
DiSEqC: switch pos 0, 18V, hiband (index 3)
tuning status == 0x02 tuning status == 0x02 tuning status == 0x02 tuning status == 0x02 tuning status == 0x02 tuning status == 0x00 tuning status == 0x02 tuning status == 0x00 tuning status == 0x02 tuning status == 0x00
WARNING: >>> tuning failed!!!
tune to: 12539:h:0:27500 (tuning failed)
ERROR: initial tuning failed dumping lists (0 services) Done.
The file "Hotbird-13.0E" contains:
# EUTELSAT SkyPlex, Hotbird 13E # freq pol sr fec S 12539000 H 27500000 3/4
In Windows everything's OK (so there's no hardware problem)
What do I do wrong?
Thank you. Mauro
Laz a écrit :
On Wednesday 18 May 2005 18:27, Nicolas Huillard wrote:
Laurence Abbott a écrit :
It's an Epia MII that I've got which has the VT1622a rather than the VT122 encoder chip and the Noscale mode wasn't available for it until I hacked one together.
What method, documents, etc. did you use to get that mode working ? I had a mail exchange with the unichrome maintainer who added the 720x576Noscale mode to CVS, but he uses tools that do not work with the frame-buffer driver. Whatever tiny information would help me.
The unichrome drivers currently use modes from a table, rather than being created on-the-fly due to a lack of info from Via. The 720x576Noscale mode for the VT1622, i.e. Epia M series and others, was written by Terry Barnaby and submitted to the unichrome-users mailing list. With some pointers from him and a bit of prodding-registers-whilst-watching-the-picture, I created a similar patch for the VT1622a found in the Epia MII that I have and he didn't. This was a few weeks back and I don't know if any of the patches have made it into the proper CVS tree or not. The structure of the mode table changed somewhere along the line, too, which added to the fun!
I plan to check what differences exist between the scaled and noscale modes in the X driver, and merge them back into the frame-buffer driver. That process will certainly exhaust my patience and time very quickly, but I think it's worth to try.
What is the DirectFB driver like? Is that using tables similarly? (I've just grabbed the latest DirectB but have yet to look at it.) I can forward a copy of the patches on to you (or this list) if you like. What modes can DirectFB do currently? I see that there is a unichrome driver and a cle266 driver: which one do I want?
I'm talking about the viafb kernel frame-buffer driver (the stuff that provide a frame-buffer interface in /dev/ The DirectFB drivers (the two ones) are abstraction layers that use the frame-buffer and add 2D acceleration, that DirectFB applications can use. I think the unichrome X driver was developped with the viafb driver from VIA as a basis. Thus the mode tables found in the viafb kernel driver were the same as the ones found in the unichrome X driver by the end of 2004. The Terry improved both the mode tables structure *and* the tables content, thus added the 720x576Noscale mode.
What I would like to do is retrofit the 720x576Noscale into the tables found inside the viafb kernel module. For this, I have to : 1) find the differences between the 720x576scaled and 720x576Noscale modes in the new table structure 2) and find where those differences should go in the old table structure (where the 720x576Noscale didn't exist) 3) modify and test the kernel frame-buffer driver
Anything that could help would be very useful, since : * the kernel module cannot be unloaded, so each test mean a reboot * the tables are inside the code, so each modification mean a recompilation (thus moprobe, thus reboot)
So if you have any tool, diff, advice, etc. I'm interested.
I'll give it a go... Debian currently doesn't have DFB++ packages, or not that I've found.
I have one, which is not very useful outside softdevice. I'll provide the necessary packages for the Debian official repository.
On Wed, 2005-05-18 at 19:27 +0200, Nicolas Huillard wrote:
I took the time make have softdevice working, and I'm really pleased of it. Join the softdevice-devel ML on BerliOS if you're interested.
Here's what I have done:
1. Patched my kernel (2.6.10) with the cle266 framebuffer patch from http://patcher2k.012webpages.com/ 2. Built a kernel with the cle266 framebuffer as a module and no VESA frambuffer 3. Grabbed DirectFB and DFB++ from CVS. 4. Built DirectFB as a debian package and installed the 3 or 4 packages it created (dependency on libflash-dev which didn't exist in Debian testing!). 5. Built DFB++ and installed to /usr/local 6. Grabbed softdevice from CVS 7. Built the softdevice plugin with a couple of tweaks to the Makefile for locations of libavcodec, DirectFB, etc. 8. Put the following in /etc/fb.modes (gleaned from various sources): mode "720x576 50Hz 16bit" geometry 720 576 720 576 16 timings 31208 144 40 32 10 128 3 bcast true endmode
mode "768x576-50i" geometry 872 576 872 576 16 timings 59550 24 102 0 0 80 1 laced true hsync high vsync high endmode
9. Put the following in /etc/directfbrc (gleaned from softdevice mailing list): mode=720x576 depth=32 pixelformat=ARGB disable-module=lirc disable-module=joystick disable-module=cle266 no-vt
If I modprobe the module and do a dfbinfo (as any user): laz@vdr-tng vdr-1.3.24 $ dfbinfo (*) DirectFB/Config: Parsing config file '/etc/directfbrc'.
---------------------- DirectFB v0.9.23 --------------------- (c) 2000-2002 convergence integrated media GmbH (c) 2002-2004 convergence GmbH -----------------------------------------------------------
(*) DirectFB/Core: Single Application Core. (2005-05-18 19:38) (*) Direct/Memcpy: Using SSE optimized memcpy() (*) Direct/Modules: suppress module 'joystick' (*) Direct/Modules: suppress module 'lirc' (*) DirectFB/Genefx: MMX detected and enabled (*) Direct/Modules: suppress module 'cle266' (*) DirectFB/Graphics: VIA/S3G UniChrome 0.4 (-) (*) DirectFB/Core/WM: Default 0.2 (Convergence GmbH) (!!!) *** UNIMPLEMENTED [fusion_reactor_set_lock] *** [../../../lib/fusion/reactor.c:802]
Screen (00) FBDev Primary Screen (primary screen) Caps: VSYNC POWER_MANAGEMENT
Layer (00) FBDev Primary Layer (primary layer) Type: GRAPHICS Caps: SURFACE BRIGHTNESS CONTRAST SATURATION
Layer (01) VIA Unichrome Video Type: GRAPHICS VIDEO STILL_PICTURE Caps: SURFACE OPACITY SCREEN_LOCATION DEINTERLACING DST_COLORKEY LEVELS SCREEN_POSITION SCREEN_SIZE
Layer (02) VIA Unichrome DVD Subpicture Type: GRAPHICS VIDEO STILL_PICTURE Caps: SURFACE OPACITY
All looked good until I tried to start vdr with -P'softdevice -vo dfb:' when I got: vdr: /home/vdr/plugins/libvdr-softdevice.so.1.3.24: undefined symbol: dts_frame
:-(
I needed to make another adjustment to the makefile, replacing the FFMPEGLIBS line with: FFMPEGLIBS = `ffmpeg-config --libs avcodec avformat postproc`
Now it's sorted and runs, although I can't see it because I'm testing it over ssh! I'll see if it is really working later on (looks good from the output).
CPU usage seems to sit around 43%, which seems higher than it was using X and xine but, presumably, it is less memory hungry like this, and also easier to start up!
;)
Cheers,
Laz
On Thu, 2005-05-19 at 10:22 +0200, Nicolas Huillard wrote:
What I would like to do is retrofit the 720x576Noscale into the tables found inside the viafb kernel module. For this, I have to :
- find the differences between the 720x576scaled and 720x576Noscale
modes in the new table structure 2) and find where those differences should go in the old table structure (where the 720x576Noscale didn't exist) 3) modify and test the kernel frame-buffer driver
Anything that could help would be very useful, since :
- the kernel module cannot be unloaded, so each test mean a reboot
- the tables are inside the code, so each modification mean a
recompilation (thus moprobe, thus reboot)
Nasty!
So if you have any tool, diff, advice, etc. I'm interested.
Have a look at the vt1622.c tool at http://cvs.sourceforge.net/viewcvs.py/unichrome/utils/
This lets you alter register values of the vt1622 o r1622a on-the-fly. This is what I used to get the Noscale table for the vt1622a. It lets you change syncs, scaling, etc., and see how it affects the picture. It can then be used to output a table entry in the format below. I got my vt1622a Noscale table entry by changing about 2 of the registers (I think) from an entry suggested by Terry. When I wrote out the table, it had a lot more than just those two values changed but it did work.
Here are the relevant table entries I have in my unichrome driver (may have changed in current CVS but hopefully you can work out which bits are which: N.B. the table entries are anonymous due to Via's NDA about what information can be released) from xc/programs/Xserver/hw/xfree86/drivers/via/via_vt1622x.h:
/* * * VT1622 modetables * */ static DisplayModeRec VT1622Modes[] = { { MODEPREFIX("720x576"), 28500, 720, 728, 744, 760, 0, 576, 635 , 643, 750, 0, V_NHSYNC | V_PVSYNC, MODESUFFIXPAL }, { MODEPREFIX("720x576Over"), 30000, 720, 728, 864, 1000, 0, 576, 576 , 579, 600, 0, V_NHSYNC | V_PVSYNC, MODESUFFIXPAL }, { MODEPREFIX("720x576Noscale"), 28000, 720, 728, 864, 896, 0, 576, 576 , 579, 625, 0, V_NHSYNC | V_NVSYNC, MODESUFFIXPAL },
static struct VT162XTableRec VT1622Table[] = { { "720x576", 720, 576, TVTYPE_PAL, 0, 0, { 0x04, 0, 0, 0xA2, 0, 0, 0x10, 0x1E, 0xAC, 0x38, 0x67, 0, 0x57, 0x49, 0x0F, 0, 0, 0, 0xF0, 0x0F, 0xD1, 0x38, 0, 0, 0, 0, 0xF2, 0, 0x02, 0, 0, 0x84, 0x13, 0x0C, 0x04, 0x7B, 0x48, 0x64, 0x30, 0x93, 0x49, 0x5F, 0x15, 0xA5, 0x23, 0x8B, 0xBD, 0 }, { 0xE7, 0x45, 0x04, 0, 0, 0x45, 0xF7, 0xD1, 0x22, 0xED, 0x02, 0x1D, 0x29, 0x75, 0x23, 0x88, 0xC6, 0xF0, 0xFA, 0x0F, 0xCC, 0x30, 0x14, 0, 0, 0x8F, 0x03 }, { 0xB5, 0xB1, 0xB1, 0, 0, 0 }, { 0x59, 0x4D, 0x4A }, 0x2D839832, 0, }, { "720x576Over", 720, 576, TVTYPE_PAL, 0, 0, { 0x04, 0, 0, 0xA6, 0, 0, 0x10, 0x10, 0x7D, 0x32, 0x60, 0, 0x57, 0x46, 0x0F, 0, 0, 0, 0xEC, 0x15, 0xDC, 0x28, 0, 0, 0, 0, 0xEE, 0, 0x0A, 0, 0, 0x84, 0x13, 0x0C, 0x04, 0x7B, 0x48, 0x64, 0x30, 0x93, 0x49, 0x5F, 0x15, 0xA5, 0x23, 0x77, 0xFF, 0 }, { 0xE7, 0x45, 0x04, 0, 0, 0x45, 0xE7, 0xCF, 0x23, 0x57, 0x02, 0x1F, 0x80, 0x75, 0x23, 0x89, 0xC7, 0xF1, 0xFF, 0x05, 0xD7, 0x80, 0x03, 0, 0, 0xBF, 0x03 }, { 0xBA, 0xB8, 0xB8, 0x90, 0x99, 0 }, { 0x58, 0x48, 0x49 }, 0x2D66772D, 0, }, { "720x576Noscale", 720, 576, TVTYPE_PAL, 0, 0, { 0x04, 0, 0, 0xA4, 0, 0, 0x10, 0x75, 0xA5, 0x3A, 0x5A, 0, 0x49, 0x46, 0, 0x89, 0, 0, 0xE9, 0x19, 0xDC, 0x24, 0, 0, 0, 0, 0xEE, 0, 0x0A, 0, 0, 0x04, 0x13, 0x0C, 0x04, 0x7B, 0x48, 0x64, 0x30, 0x93, 0x49, 0x5F, 0x15, 0xA5, 0x23, 0x77, 0xFF, 0 }, { 0xE7, 0x45, 0x04, 0, 0, 0x45, 0x7F, 0xD0, 0x23, 0x70, 0x02, 0x7F, 0xD0, 0x93, 0x23, 0x89, 0xC7, 0xF1, 0xBD, 0x06, 0, 0, 0, 0, 0, 0x7F, 0x03 }, { 0xBA, 0xB8, 0xB8, 0x90, 0x99, 0 }, /* added later - untested */ { 0x58, 0x48, 0x49 }, /* added later - untested */ 0x288933E3, 0, },
/* * * VT1622A/VT1623 modetables * */ static DisplayModeRec VT1623Modes[] = { { MODEPREFIX("720x576"), 28500, 720, 728, 744, 760, 0, 576, 635, 643, 750, 0, V_NHSYNC | V_PVSYNC, MODESUFFIXPAL }, { MODEPREFIX("720x576Over"), 27000, 720, 768, 800, 864, 0, 576, 577, 579, 625, 0, V_NHSYNC | V_PVSYNC, MODESUFFIXPAL }, { MODEPREFIX("720x576Noscale"), 28000, 720, 728, 864, 896, 0, 576, 576 , 579, 625, 0, V_NHSYNC | V_NVSYNC, MODESUFFIXPAL },
static struct VT162XTableRec VT1623Table[] = { { "720x576", 720, 576, TVTYPE_PAL, 0, 0, { 0x04, 0, 0, 0x06, 0, 0, 0x20, 0x0F, 0xAF, 0x35, 0x5D, 0, 0x4F, 0x41, 0x0F, 0, 0, 0, 0xF8, 0x3C, 0x73, 0x56, 0, 0, 0, 0, 0xED, 0, 0x02, 0, 0, 0x99, 0x18, 0x0C, 0x76, 0x7A, 0x44, 0x62, 0x30, 0x8E, 0x49, 0x5B, 0x15, 0xA0, 0x22, 0x5C, 0xBD, 0 }, { 0, 0, 0, 0, 0, 0x43, 0xF7, 0xCF, 0x22, 0xED, 0x02, 0x1D, 0x29, 0x75, 0x63, 0x88, 0xC6, 0xF0, 0xFA, 0x0F, 0xCC, 0x30, 0x94, 0, 0, 0x8F, 0x03 }, { 0x6A, 0x62, 0x65, 0, 0, 0 }, { 0x59, 0x4D, 0x4A }, 0x2D839832, 0, }, { "720x576Over", 720, 576, TVTYPE_PAL, 0, 0, { 0x04, 0, 0, 0, 0, 0, 0x20, 0x3F, 0x89, 0x35, 0x50, 0, 0x43, 0x2E, 0x0F, 0, 0, 0, 0xE8, 0x23, 0x84, 0x20, 0, 0, 0, 0, 0xFF, 0, 0x02, 0, 0, 0x99, 0x17, 0x0C, 0x6F, 0x79, 0x48, 0x62, 0x34, 0x8E, 0x4F, 0x5B, 0x15, 0xA0, 0x22, 0x67, 0xFF, 0 }, { 0, 0, 0, 0, 0, 0x3A, 0x5F, 0xCF, 0x23, 0x70, 0x02, 0x5F, 0xBF, 0x7E, 0x23, 0x94, 0xD0, 0x27, 0x8F, 0x16, 0, 0, 0x04, 0, 0, 0x5F, 0x03 }, { 0x6A, 0x62, 0x65, 0x90, 0x99, 0 }, { 0x58, 0x48, 0x49 }, 0x2A098ACB, 0, }, { "720x576Noscale", 720, 576, TVTYPE_PAL, 0, 0, { 0x04, 0, 0, 0x00, 0, 0, 0x20, 0x75, 0xA5, 0x3A, 0x5A, 0, 0x49, 0x46, 0, 0x89, 0, 0, 0xE9, 0x19, 0x6E, 0x24, 0, 0, 0, 0, 0xEE, 0, 0x0A, 0, 0, 0x00, 0x13, 0x0C, 0x04, 0x7B, 0x48, 0x64, 0x30, 0x93, 0x49, 0x5F, 0x15, 0xA5, 0x23, 0x77, 0xFF, 0 }, { 0x00, 0x00, 0x04, 0, 0, 0x45, 0x7F, 0x4B, 0x33, 0x70, 0x02, 0x7F, 0xD0, 0x93, 0x23, 0x89, 0xC7, 0xF1, 0xBD, 0x06, 0, 0, 0, 0, 0, 0x7F, 0x03 }, { 0xBA, 0xB8, 0xB8, 0x90, 0x99, 0 }, /* added later - untested */ { 0x58, 0x48, 0x49 }, /* added later - untested */ 0x288933E3, 0, },
Yummy!
;)
I hope that is of some use to you. Let me know if you want the whole file sending!
I'll give it a go... Debian currently doesn't have DFB++ packages, or not that I've found.
I have one, which is not very useful outside softdevice. I'll provide the necessary packages for the Debian official repository.
Cool.
Cheers,
Laz
tony wrote:
I do not have any issues with interlacing (maybe because my screen is small) on digital signals.
I cannot say much about the EPIA TV-out or VGA/DVI, but I do have some experience in de-interlacing technology, so I'm sure this must be an issue.
As long as the video material is progressive (like movies usually), everything is fine. But if the material is real interlaced, de-interlacing must be done.
Most simple way is weaving, but this gives noticeable comb-like artifacts on anything that moves. Really ugly.
Second most simple is bobbing, interpolate missing lines. This degrades vertical resolution noticeably and gives pixel steps on diagonal lines and round corners. Some may know this from DVB still pictures: DVB switches from interlaced to simple bob-like skip-field in pause mode.
Another simple is averaging: Blend half frames together. Used together with bobbing to bring back some resolution, but introduces shadow pictures that can be seen even in live video.
Most common is adaptive weave/bob or adaptive weave/average: Use weaving for non-moving areas and bobbing/averaging for moving areas. Quality depends noticeable on the quality of the motion detection and will give either weave or bob/average artifacts sometimes. In any case, moving things like stock ticker on news channels will be bobbed/averaged, giving lower quality.
High-end are motion interpolation technologies that actually track moving parts of the picture and interpolate missing lines by using motion-interpolated lines. While doing this, its even possible to smoothly increase the frame rate without introducing judder.
These high-end systems are used in better 100Hz tube TVs and flat screen TVs, running on specialized signal processors. A computer implementation of this method is available in WinDVD6 , but requires a whopping 3GHz CPU power to run smoothly. (Trimension[1] licensed from Philips)
Based on that, my conclusion is that de-interlacing is done best inside the TV, not in the PC, and that means output as PAL720x576noscale without de-interlacing, no matter what connector you use, though this will be challenging on VGA/DVI.
Cheers,
Udo
En/na Nicolas Huillard ha escrit:
Sebastian a écrit :
Seems like many people actually like using an EPIA with a budget card. What I would like to know is what possibilities are there to connect to a TV set? I mean the Epia just features a simple fbas tv-out, right? So that's a downside, because with a J2 pinblock on a FF card you can use RGB or S-Video instead of FBAS. Or am I missing anything?
EPIA M also have a s-video connector. Maybe you are refering to older EPIAs without this conneector. Better quality is achieved using the VGA connector to a LCD/plasma TV. And I mean really better quality. Tony Grant could explain more on this. You can also directly use your average CRT monitor, which is already far better than any TV.
Well after this a lot of information I have decided try to set VDR with only one DVB-t budget pci card. I have a FF dvb-s card but epia have only one pci and I dont have the riser card to get 2 pci's from the one pci of the epia. If I obtain good results without FF card (using HW accel from epia CLE266) I will buy a bugdet dvb-s card, probably nova-s from haupaugge.
My TV is a normal Loewe 100Hz with scarts. My htpc case is the Silverstone LC11M (front 2 lines display and ir) My distro is debian The kernel I have thought to use is the 2.6.11.10 with the config file from epiawiki.org:
Mostly-minimalist .config file for a Epia M or M2 used as a multi-media server. Based on Gentoo 2.6.11-r5. is located here: http://www.epiawiki.org/wiki/tiki-download_file.php?fileId=14
And add the dvb driver in the kernel. I supose that the next steps can be: - lirc - softdevice? (I supose that I have to use the s-vga to scart connection from epia to my TV
But I continue having dubts and a lot of information that confuse me. The last post by Laurence Abbott has left me outside orbits.
I don't understand if is better to me use softdevice or xine and how to set X without desktop. - display plugin? (anyone can tell me one?)
I have set up a VDR in a normal PC compiling it from source code and the usual plugins. Do you recommend continue this way or is better use the etobi debian packages? What advantages has each method?
In the other hand I'm sure this experience will get to me some knowledge that I want to share with VDR newbies and experts. But in my language, spanish. Perhaps I publish a spanish VDR wiki or similar.
Thanks for all to all!!
Leo Márquez a écrit :
En/na Nicolas Huillard ha escrit:
Sebastian a écrit :
Seems like many people actually like using an EPIA with a budget card. What I would like to know is what possibilities are there to connect to a TV set? I mean the Epia just features a simple fbas tv-out, right? So that's a downside, because with a J2 pinblock on a FF card you can use RGB or S-Video instead of FBAS. Or am I missing anything?
EPIA M also have a s-video connector. Maybe you are refering to older EPIAs without this conneector. Better quality is achieved using the VGA connector to a LCD/plasma TV. And I mean really better quality. Tony Grant could explain more on this. You can also directly use your average CRT monitor, which is already far better than any TV.
Well after this a lot of information I have decided try to set VDR with only one DVB-t budget pci card. I have a FF dvb-s card but epia have only one pci and I dont have the riser card to get 2 pci's from the one pci of the epia. If I obtain good results without FF card (using HW accel from epia CLE266) I will buy a bugdet dvb-s card, probably nova-s from haupaugge.
My TV is a normal Loewe 100Hz with scarts. My htpc case is the Silverstone LC11M (front 2 lines display and ir) My distro is debian The kernel I have thought to use is the 2.6.11.10 with the config file from epiawiki.org:
Mostly-minimalist .config file for a Epia M or M2 used as a multi-media server. Based on Gentoo 2.6.11-r5. is located here: http://www.epiawiki.org/wiki/tiki-download_file.php?fileId=14
This config does not have the viafb frame-buffer set, but DRM is. This is maybe aimed at X setup, not frame-buffer/DirectFB.
And add the dvb driver in the kernel. I supose that the next steps can be:
- lirc - softdevice? (I supose that I have to use the s-vga to
scart connection from epia to my TV
You mean "s-video" connector (round, yellow), not vga (d-sub, blue).
But I continue having dubts and a lot of information that confuse me. The last post by Laurence Abbott has left me outside orbits.
I don't understand if is better to me use softdevice or xine and how to set X without desktop.
softdevice = no X, just VDR. You won't have the possibility to add a browser, for instance.
Xine works best on EPIA with XvMC, so it needs X, and you will have the possibility to use the computer for something else than VDR (if you add a keyboard, a mouse, and so on).
You can maybe just test each one ?
How to set X without desktop : install XFree, don't run /etc/init.d/gdm at startup, then type "startx" on a console. This will bring X for your login, with a single xterm. No window manager, awful look. Type ^D in the xterm, this will quit X an return to the console. That's the old-fashionned way to start X (thus the name of the command). Add commands to you ~/.xinitrc script and these will be executed inside you X session, instead of the single xterm.
- display plugin? (anyone can tell me one?)
The display plugin is either softdevice or vdr-xine or xineliboutput. Just choose.
I have set up a VDR in a normal PC compiling it from source code and the usual plugins. Do you recommend continue this way or is better use the etobi debian packages? What advantages has each method?
e-tobi won't bring you softdevice for the moment. I don't know for vdr-xine, but XvMC is not part of XFree on Debian. Use another repository for that (http://www.physik.fu-berlin.de/~glaweh/debian/) Get the e-tobi packages that are available, and compile the missing ones yourself. As long as you do not patch VDR, you won't have to recompile too much. If you start to patch VDR, you have to recompile everything.
In the other hand I'm sure this experience will get to me some knowledge that I want to share with VDR newbies and experts. But in my language, spanish. Perhaps I publish a spanish VDR wiki or similar.
Thanks for all to all!!
En/na Nicolas Huillard ha escrit:
Leo Márquez a écrit :
En/na Nicolas Huillard ha escrit:
Sebastian a écrit :
Seems like many people actually like using an EPIA with a budget card. What I would like to know is what possibilities are there to connect to a TV set? I mean the Epia just features a simple fbas tv-out, right? So that's a downside, because with a J2 pinblock on a FF card you can use RGB or S-Video instead of FBAS. Or am I missing anything?
EPIA M also have a s-video connector. Maybe you are refering to older EPIAs without this conneector. Better quality is achieved using the VGA connector to a LCD/plasma TV. And I mean really better quality. Tony Grant could explain more on this. You can also directly use your average CRT monitor, which is already far better than any TV.
Well after this a lot of information I have decided try to set VDR with only one DVB-t budget pci card. I have a FF dvb-s card but epia have only one pci and I dont have the riser card to get 2 pci's from the one pci of the epia. If I obtain good results without FF card (using HW accel from epia CLE266) I will buy a bugdet dvb-s card, probably nova-s from haupaugge.
My TV is a normal Loewe 100Hz with scarts. My htpc case is the Silverstone LC11M (front 2 lines display and ir) My distro is debian The kernel I have thought to use is the 2.6.11.10 with the config file from epiawiki.org:
Mostly-minimalist .config file for a Epia M or M2 used as a multi-media server. Based on Gentoo 2.6.11-r5. is located here: http://www.epiawiki.org/wiki/tiki-download_file.php?fileId=14
This config does not have the viafb frame-buffer set, but DRM is. This is maybe aimed at X setup, not frame-buffer/DirectFB.
And add the dvb driver in the kernel. I supose that the next steps can be:
- lirc - softdevice? (I supose that I have to use the s-vga to
scart connection from epia to my TV
You mean "s-video" connector (round, yellow), not vga (d-sub, blue).
Yes! sorry I meant s-video
But I continue having dubts and a lot of information that confuse me. The last post by Laurence Abbott has left me outside orbits.
I don't understand if is better to me use softdevice or xine and how to set X without desktop.
softdevice = no X, just VDR. You won't have the possibility to add a browser, for instance.
HW acceleration using CLE266?
Xine works best on EPIA with XvMC, so it needs X, and you will have the possibility to use the computer for something else than VDR (if you add a keyboard, a mouse, and so on).
You can maybe just test each one ?
How to set X without desktop : install XFree, don't run /etc/init.d/gdm at startup, then type "startx" on a console. This will bring X for your login, with a single xterm. No window manager, awful look. Type ^D in the xterm, this will quit X an return to the console. That's the old-fashionned way to start X (thus the name of the command). Add commands to you ~/.xinitrc script and these will be executed inside you X session, instead of the single xterm.
I supose It's possible to execute automatically this with a init.d script.It's ok?
- display plugin? (anyone can tell me one?)
The display plugin is either softdevice or vdr-xine or xineliboutput. Just choose.
I'm refering to the VFD display of the htpc case.
I have set up a VDR in a normal PC compiling it from source code and the usual plugins. Do you recommend continue this way or is better use the etobi debian packages? What advantages has each method?
e-tobi won't bring you softdevice for the moment. I don't know for vdr-xine, but XvMC is not part of XFree on Debian. Use another repository for that (http://www.physik.fu-berlin.de/~glaweh/debian/) Get the e-tobi packages that are available, and compile the missing ones yourself. As long as you do not patch VDR, you won't have to recompile too much. If you start to patch VDR, you have to recompile everything.
In the other hand I'm sure this experience will get to me some knowledge that I want to share with VDR newbies and experts. But in my language, spanish. Perhaps I publish a spanish VDR wiki or similar.
Thanks for all to all!!
Leo Márquez a écrit :
En/na Nicolas Huillard ha escrit:
...
softdevice = no X, just VDR. You won't have the possibility to add a browser, for instance.
HW acceleration using CLE266?
...is synomynous of XvMC, thus currently achieved only with Xine + X + vdr-xine or with xineliboutput.
...
- display plugin? (anyone can tell me one?)
The display plugin is either softdevice or vdr-xine or xineliboutput. Just choose.
I'm refering to the VFD display of the htpc case.
Sorry. I think your VFD is a character display, which mandates the use of the lcdproc plugin. I don't know much about this one, except that it's not announced often on this list...
Hi Tony,
My TV has a VGA in, too.
OK cool just use the VGA, that will give you the best picture and at no extra cost! Yay!
Great! I already downloaded all the needed stuff (viafb, DirectFB, DFB++, softdevice) from CVS and compiled it (over ssh, so I cannot test now).
What resolution/mode should I choose?
I remember some months ago, when I played around with X on the EPIA, I couldn't get a good picture in 16:9, only with 4:3 (1024x768).
I hope this is not a problem with my TV. It's a LCD, 16:9, and it claims to have a resolution of 1280x768 IIRC. But X and DDC did not report such a mode, only 1024x768.
The TV remote control I can switch between 4:3, 16:9 and "Zoom". The 16:9 mode simply stretches the 4:3 image horizontally so that it covers the whole screen.
I got a really crispy image with 1024x768 in 4:3 mode (the default X background didn't show any moire effect), but large black borders on both sides.
I couldn't get such a clear picture in 16:9 mode, I tried a lot of X11 modelines, but failed....
I'll play around with this in the evening.
Are there any (simple) test programs for DirectFB and friends? Some "test images" where I can tell that there's nothing "invisible" (outside the screen borders), a good pixel match (no moire/interpolation) and so on?
TIA, Michael
Michael Reinelt a écrit :
Are there any (simple) test programs for DirectFB and friends? Some "test images" where I can tell that there's nothing "invisible" (outside the screen borders), a good pixel match (no moire/interpolation) and so on?
I collected some, available on http://nicolas.huillard.net/vdr/tv_test/
Lucian Muresan generated some for me from a Nokia Windows app available on http://www.idg.pl/ftp/download/pc_2678/Ntest2.exe
Just use the dfbshow program to show them on screen. Adjust /etc/directfbrc to change resolution.
Nicolas Huillard schrieb:
Michael Reinelt a écrit :
Are there any (simple) test programs for DirectFB and friends? Some "test images" where I can tell that there's nothing "invisible" (outside the screen borders), a good pixel match (no moire/interpolation) and so on?
I collected some, available on http://nicolas.huillard.net/vdr/tv_test/
Wonderful! That's exactly what I've been looking for! Thanks a lot!
bye, Michael
On Thursday 19 May 2005 18:53, Stefan Lucke wrote:
On Donnerstag, 19. Mai 2005 10:52, Laurence Abbott wrote:
I needed to make another adjustment to the makefile, replacing the FFMPEGLIBS line with: FFMPEGLIBS = `ffmpeg-config --libs avcodec avformat postproc`
ffmpeg-config: where doe this command come from ?
Under Debian, it is part of the libavcodec-dev package. Looking at the manual page for it:
ffmpeg-config(1) ffmpeg-config(1)
NAME ffmpeg-config - script to get information about the installed version of ffmpeg
SYNOPSIS ffmpeg-config [ --prefix= DIR] [ --version ] [ --libs [<extensions>]] [ --plugin-libs [<extensions>]] [ --cflags ]
{snip}
AUTHOR This manual page was written for sdl-config by Branden Robinson, origi- nally for Progeny Linux Systems, Inc., and the Debian Project. It was adapted to ffmpeg by Sam Hocevar.
ffmpeg 2004-07-16 ffmpeg-config(1)
Looks like it might be debian specific, although I'm pretty sure things like that exist for Gentoo as well.
It gives the correct cflags, libflags, etc.:
laz@vdr-tng laz $ ffmpeg-config --libs -lvorbis -lvorbisenc -ldts -la52 -lz -lm laz@vdr-tng laz $
laz@vdr-tng laz $ ffmpeg-config --libs avcodec avformat postproc -lavcodec -lavformat -lavcodec -lpostproc -lavcodec -lvorbis -lvorbisenc -ldts -la52 -lz -lm laz@vdr-tng laz $
Cheers,
Laz
On Donnerstag, 19. Mai 2005 21:56, Laz wrote:
On Thursday 19 May 2005 18:53, Stefan Lucke wrote:
On Donnerstag, 19. Mai 2005 10:52, Laurence Abbott wrote:
I needed to make another adjustment to the makefile, replacing the FFMPEGLIBS line with: FFMPEGLIBS = `ffmpeg-config --libs avcodec avformat postproc`
ffmpeg-config: where doe this command come from ?
Under Debian, it is part of the libavcodec-dev package. Looking at the manual page for it:
ffmpeg-config(1) ffmpeg-config(1)
Thanks, but that seems to be distribution specific. I do not have this command. AHH, my question is a bit to late, as I've seen now, ffmpeg has pkg-config support (since 20 hours). That makes build step a bit easier :-) .
stefan@jarada:~> pkg-config --cflags libavcodec -I/usr/local/include -I/usr/local/include/ffmpeg stefan@jarada:~> pkg-config --libs libavformat -L/usr/local/lib -lavformat -lavcodec -lm -lz -ldl stefan@jarada:~> pkg-config --libs libavcodec -L/usr/local/lib -lavcodec -lm -lz -ldl
laz@vdr-tng laz $ ffmpeg-config --libs -lvorbis -lvorbisenc -ldts -la52 -lz -lm
tz, tz, tz .
Nicolas Huillard schrieb:
but the summary would be like :
- use standard kernel
- add the viafb frame-buffer driver from http://patcher2k.012webpages.com/
- compile viafb as a module, but no vesafb or cle266vgaio (IIRC)
- /etc/directfbrc and /etc/fb.modes have to be cleaned up
- get DirectFB, DFB++, FFmpeg, et al. from CVS (older version might work)
- compile softdevice and enjoy !
Little problems I still have are related to /etc/directfbrc.
Help!
I'm trying to get softdevice up and running on my EPIA-M6000, but I fail in a very early stage :-(
I'm using a vanilla kernel 2.6.11 and applied the viafb patch from patcher2k. I also compiled DirectFB from CVS.
When I boot, I get normal VGA textmode on the console. As soon as I load the viafb module, I get garbage on the screen. I tried a lot of different module parameters, no difference.
Some of the dfb commands are working, but I see no result on the screen.
If I try to change the resolution with either fbset or dfbswitch, either nothing happens, or (even worse) my TV (connected via VGA input) looses the signal. A reboot is the only way I found so far to get a signal back.
I tried to compile the viafb driver from viaarena, but this driver does not compile with my 2.6.11 kerenl (lots of warnings, and errors about "structure has no member 'cursor').
Looks like I'm far away from using softdevice, but I want to display the test pictures from Nicolas!
Any help would be greatly appreciated!
TIA, Michael
Michael Reinelt a écrit :
Nicolas Huillard schrieb:
but the summary would be like :
- use standard kernel
- add the viafb frame-buffer driver from http://patcher2k.012webpages.com/
- compile viafb as a module, but no vesafb or cle266vgaio (IIRC)
- /etc/directfbrc and /etc/fb.modes have to be cleaned up
- get DirectFB, DFB++, FFmpeg, et al. from CVS (older version might work)
- compile softdevice and enjoy !
Little problems I still have are related to /etc/directfbrc.
Help!
I'm trying to get softdevice up and running on my EPIA-M6000, but I fail in a very early stage :-(
I'm using a vanilla kernel 2.6.11 and applied the viafb patch from patcher2k. I also compiled DirectFB from CVS.
When I boot, I get normal VGA textmode on the console. As soon as I load the viafb module, I get garbage on the screen. I tried a lot of different module parameters, no difference.
The viafb driver has problems, for sure. You must also load the fbcon kernel module (I'm not sure about what kernel options make it compile). This one allows tghe kernel to use a frame-buffer console. Needed on 2.6, not on 2.4, and only if you use the console keyboard/screen. You should try everything related to viafb over a remote shell (SSH), in order to keep control of the computer. My /etc/modules : viafb mode=720x576 bpp=32 refresh=50 TVon=1 TVoverscan=1 fbcon
Some of the dfb commands are working, but I see no result on the screen.
If I try to change the resolution with either fbset or dfbswitch, either nothing happens, or (even worse) my TV (connected via VGA input) looses the signal. A reboot is the only way I found so far to get a signal back.
I tried to compile the viafb driver from viaarena, but this driver does not compile with my 2.6.11 kerenl (lots of warnings, and errors about "structure has no member 'cursor').
This one is old and closed-source, isn't it ?
Looks like I'm far away from using softdevice, but I want to display the test pictures from Nicolas!
You'll get them : fbcon + SSH + dfbshow I just modify /etc/directfbrc to change the DirectFB resolution (gets back to 720x576 when quitting the DFB app). My /etc/directfbrc : mode=720x576 #mode=800x600 #mode=1024x768 depth=32 pixelformat=ARGB disable-module=lirc disable-module=joystick disable-module=cle266 #graphics-vt #no-graphics-vt #no-vt-switch #no-vt-switching no-vt
Try the '*vt*' options after reading the man pages and the ML archives (vdr or directfb-users).
Hi Nicolas!
First the good news: It works! I can see a picture! Thanks a lot!
I'm not shure what was wrong before, but maybe I made a big mistake: dfbg sets the background, but only for a very short time. Looks like that it switches back to a black screen after exit.
I found another strange thing in my syslog:
kernel: viafb: 0 interrupt requests serviced. kernel: viafb: VIA UNICHROME framebuffer 1.0 initializing kernel: viafb: viafb : DCB80000 kernel: viafb: framebuffer size = 64 Mb kernel: viafb: Found Device Rev:0 kernel: viafb: X:1024 Y:768 kernel: viafb: mode=1024 bpp=32 refresh=60 TVon=0 TVtype=1 kernel: viafb: VQ start:3FC0000 end:3FFFFFF size:40000 kernel: viafb: Cursor start:3FBF000 end:3FBFFFF size:1000 kernel: viafb: mode=1024 bpp=32 refresh=255 TVon=0 TVtype=1 kernel: setmode x:1024 y:768 bpp:32 kernel: viafb: irq handler installed, IRQ(0x200) = 80080c02 kernel: fb0: UNICHROME frame buffer device
What is the second "refresh=255" about?
You must also load the fbcon kernel module (I'm not sure about what kernel options make it compile). This one allows tghe kernel to use a frame-buffer console. Needed on 2.6, not on 2.4, and only if you use the console keyboard/screen.
I did not use fbcon, cause I don't need it. My HTPC is a set-top-box only, I don't even have a keyboard connected.
*Not* using fbcon has another *real big* advantage: This way you can unload and reload the viafb module with different parameters!
viafb mode=720x576 bpp=32 refresh=50 TVon=1 TVoverscan=1
I had to use TVon=0 because my TV has VGA-in and is connected to the VGA of the Epia.
I tried to compile the viafb driver from viaarena, but this driver does not compile with my 2.6.11 kerenl (lots of warnings, and errors about "structure has no member 'cursor').
This one is old and closed-source, isn't it ?
Well, the last release seems to be from Feb 2005, so not that old...
My /etc/directfbrc : mode=720x576 #mode=800x600 #mode=1024x768
720x576 does not work here, but 800x600, 1024x768, and even 1280x768 (which seems to be the real resolution of my 16:9 TV)
But the TV does nasty things: looks like it scales the 1280 down to 1024, and then back to 1280 when switched to 16x9 :-( Ihave to investigate this further....
disable-module=cle266
Hmmm... why should I disable the cle266 module???
bye, Michael
Michael Reinelt a écrit :
Hi Nicolas!
First the good news: It works! I can see a picture! Thanks a lot!
I'm not shure what was wrong before, but maybe I made a big mistake: dfbg sets the background, but only for a very short time. Looks like that it switches back to a black screen after exit.
From the man : "dfbg is a small utility to configure the background of the DirectFB desktop. It loads the specified image and sets it as background image. dfbg requires DirectFB with the multi-application core enabled."
This app has a purpose when a desktop/multi-app/window-manager case. When run from the console without a desktop, it switches to DirectFB, set the background, and quits DirectFB ("very short time").
I found another strange thing in my syslog:
kernel: viafb: 0 interrupt requests serviced. kernel: viafb: VIA UNICHROME framebuffer 1.0 initializing kernel: viafb: viafb : DCB80000 kernel: viafb: framebuffer size = 64 Mb kernel: viafb: Found Device Rev:0 kernel: viafb: X:1024 Y:768 kernel: viafb: mode=1024 bpp=32 refresh=60 TVon=0 TVtype=1 kernel: viafb: VQ start:3FC0000 end:3FFFFFF size:40000 kernel: viafb: Cursor start:3FBF000 end:3FBFFFF size:1000 kernel: viafb: mode=1024 bpp=32 refresh=255 TVon=0 TVtype=1 kernel: setmode x:1024 y:768 bpp:32 kernel: viafb: irq handler installed, IRQ(0x200) = 80080c02 kernel: fb0: UNICHROME frame buffer device
What is the second "refresh=255" about?
Don't know, but this driver is known not to be fully good...
You must also load the fbcon kernel module (I'm not sure about what kernel options make it compile). This one allows tghe kernel to use a frame-buffer console. Needed on 2.6, not on 2.4, and only if you use the console keyboard/screen.
I did not use fbcon, cause I don't need it. My HTPC is a set-top-box only, I don't even have a keyboard connected.
*Not* using fbcon has another *real big* advantage: This way you can unload and reload the viafb module with different parameters!
Great. That will help me tuning the VT1622 table !
...
My /etc/directfbrc : mode=720x576 #mode=800x600 #mode=1024x768
720x576 does not work here, but 800x600, 1024x768, and even 1280x768 (which seems to be the real resolution of my 16:9 TV)
But the TV does nasty things: looks like it scales the 1280 down to 1024, and then back to 1280 when switched to 16x9 :-( Ihave to investigate this further....
Many people would be interested by your findings (including me). Did you try read-edid to get what the TV advertises via DDC
disable-module=cle266
Hmmm... why should I disable the cle266 module???
The module named cle266 is the gfx driver version 0.3, superseded by a 0.4 version, named unichrome. Since both want to handle the VGA chip, you have to disable one...
I demand that Michael Reinelt may or may not have written...
[snip]
I remember some months ago, when I played around with X on the EPIA, I couldn't get a good picture in 16:9, only with 4:3 (1024x768).
I hope this is not a problem with my TV. It's a LCD, 16:9, and it claims to have a resolution of 1280x768 IIRC. But X and DDC did not report such a mode, only 1024x768.
I have access to an LCD TV (Techwood 17LW1) which, when I tried it, reported that it has a 1280x768 mode:
Mode "1280x768" # D: 64.998 MHz, H: 48.362 kHz, V: 60.002 Hz DotClock 79.5 HTimings 1280 1344 1472 1664 VTimings 768 771 778 798 Flags "-HSync" "-VSync" EndMode
[snip]
Hi,
But the TV does nasty things: looks like it scales the 1280 down to 1024, and then back to 1280 when switched to 16x9 :-( Ihave to investigate this further....
Many people would be interested by your findings (including me). Did you try read-edid to get what the TV advertises via DDC
I did some more tests yesterday, and I created lots of test pictures in 1024x768 and 1280x768 resolution. (Is there a place where I could provide them to the public?)
First the bad news: I cannot read/decode the DDC data with read-edid:
artus.reinelt:~ # get-edid | parse-edid get-edid: get-edid version 1.4.1
Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful
VBE version 300 VBE string at 0xc52c8 "VIA CLE266"
VBE/DDC service about to be called Report DDC capabilities
Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful
Monitor and video card combination does not support DDC1 transfers Monitor and video card combination supports DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer
Reading next EDID block
VBE/DDC service about to be called Read EDID
Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call successful
parse-edid: parse-edid version 1.4.1 parse-edid: EDID checksum passed.
# EDID version 1 revision 1 Section "Monitor" # Block type: 2:0 3:0 # Block type: 2:0 3:0 # Block type: 2:0 3:fc Identifier "TCL LCD3026T" VendorName "TCL" ModelName "TCL LCD3026T" # Block type: 2:0 3:0 # Block type: 2:0 3:0 # Block type: 2:0 3:fc # Block type: 2:0 3:0 # DPMS capabilities: Active off:no Suspend:no Standby:yes
# Block type: 2:0 3:0 # Block type: 2:0 3:0 # Block type: 2:0 3:fc # Block type: 2:0 3:0 EndSection
Maybe parse-edid cannot decode DDC2 data? I remember reading something in the manual....
But I'm shure the TV does provide this data, along with a mode of 1280x768: I've been booting some "system info CD" from the german computer magazine "c't" yesterday, some of the test programs did report a lot of modes (but no further timing information).
Is there any other possibility to get the DDC data with linux?
Next I played around with modes for viafb: I get a 1280x768 mode with this options:
modprobe viafb mode=1280x768 bpp=32 refresh=60 TVon=0
I get a quite good picture where the 1280x768 fit exactly onto the screen (after some fine-tunig in the TV setup). But as I feared: the horizontal resolution isn't that good. I get a sharp resolution vertically, I can see that one pixel on the TV directly corresponds to one pixel in the test image. Horizontally, the pixels are blurred over 2-3 pixels. I have to switch the TV into 16:9 mode, in 4:3 mode the image is scaled down to 1024 pixels. I'm afraid the TV does *always* scale down to 1024, and then back up to 1280. Who the hell did design this braindamadged thing???
Next I tried to play around with 1024x768. Now for the bad news: I couldn't get a good picture here. First, the only way to get a signal on the TV is
modprobe viafb mode=1024x768 bpp=32 refresh=50 TVon=1 TVtype=1 TVoverscan=1
(note the TVon=1!!)
As soon as I set TVon to 0, I get "no signal" or "not receiving" on the TV. Maybe some of the modes in viafb are wrong?
But even with the TVon=1 mode, the resulting image isn't 1024x768, but somewhat smaller ( I suppose about 800x600 or so). I think here are some wrong mode values, too.
Next I will play with softdevice and try to get VDR on viafb up and running.
Last questions: is this the right ML for this stuff, or is it a bit OT here?
bye, Michael
Michael Reinelt a écrit :
I did some more tests yesterday, and I created lots of test pictures in 1024x768 and 1280x768 resolution. (Is there a place where I could provide them to the public?)
Send them via private mail, and I'll put them on my web space, along with the other ones. I get 107 page views (not image download) per month on this directory : it must be useful to some.
...
Next I played around with modes for viafb: I get a 1280x768 mode with this options:
modprobe viafb mode=1280x768 bpp=32 refresh=60 TVon=0
I get a quite good picture where the 1280x768 fit exactly onto the screen (after some fine-tunig in the TV setup). But as I feared: the horizontal resolution isn't that good. I get a sharp resolution vertically, I can see that one pixel on the TV directly corresponds to one pixel in the test image. Horizontally, the pixels are blurred over 2-3 pixels. I have to switch the TV into 16:9 mode, in 4:3 mode the image is scaled down to 1024 pixels. I'm afraid the TV does *always* scale down to 1024, and then back up to 1280. Who the hell did design this braindamadged thing???
Well, it is not really astoniching, taking into account the skills or common customers... I think they simply design their 16:9 panels with the same components as the 4:3 ones, and ignore anything that is not obvious. Since VGA as always been 4:3 (until a few years), they stick to it.
Next I tried to play around with 1024x768. Now for the bad news: I couldn't get a good picture here. First, the only way to get a signal on the TV is
modprobe viafb mode=1024x768 bpp=32 refresh=50 TVon=1 TVtype=1 TVoverscan=1
(note the TVon=1!!)
This places to VGA chip into special refresh rates that fit the TV encoder. These rates work with a multiscan monitor, but not with your TV. There again : cheap design.
As soon as I set TVon to 0, I get "no signal" or "not receiving" on the TV. Maybe some of the modes in viafb are wrong?
Might be, but IMHO the TV is also wrong.
But even with the TVon=1 mode, the resulting image isn't 1024x768, but somewhat smaller ( I suppose about 800x600 or so). I think here are some wrong mode values, too.
Since the TV encoder fits the image in a PAL frame, and does not do wonderful things, the VGA chip must provide degraded resolution, also shown on the VGA output.
Next I will play with softdevice and try to get VDR on viafb up and running.
Try my Debian package (http://nicolas.huillard.net/vdr/debian/ : recompile it) or the one from Tobias Grimm (improved from mine) in alioth.debian.org's SVN repository. Also softdevice and softplay developers prepare a release real soon now (this week-end).
Last questions: is this the right ML for this stuff, or is it a bit OT here?
The original post was slightly OT, and derived to completely OT in many directions... The right ML are softdevice-devel@berlios.de and directfb-users@directfb.org (viafb, DirectFB, TV-out). Start a new thread there.
-
Christian Holpert -
Darren Salt -
Laurence Abbott -
Laz
-
Leo Márquez -
mauro.folcarelli＠sistinf.it -
Michael Reinelt -
Nicolas Huillard -
Sebastian -
Stefan Lucke -
tony -
Torgeir Veimo -
Udo Richter