I want to replace my UK Sky digital box with VDR (I only want the free to air channels) for watching/recording TV over HDMI on my plasma. So far everything is working OK, I have vdr 1.7.3 and xine running on an ASUS M2N VM-HDMI (nvidia) mobo with the s2-liplianin drivers for my Nova SD2 card. My problem is interlacing. I've googled back through the archives and got a lot of info from there, however I still have one question and one request.
If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do any de interlacing in xine, why is this not the same as what my digibox does? I'm guessing it has something to do with xine outputting a complete frame when the broadcast sends each field? What I'd hope happen (for interlaced material) is that xine receives a field from VDR, scales it to the X resolution (halfed vertically of course) and sends it to the the graphics card which just passes it on to the TV which draws that field. That doesn't seem to happen so where have I gone wrong?
There's a lot of options for tvtime in xine, TomsMoComp and full framerate seem popular. What settings are others using?
-- Scott
Hi Scott!
2009/1/19 Scott Waye scott@waye.co.uk:
If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do any de interlacing in xine, why is this not the same as what my digibox does? I'm guessing it has something to do with xine outputting a complete frame when the broadcast sends each field?
What you state above is NOT correct. When you use your digiboxx, your TV panel does all interlacing and scaling. To do what your digibox does, you should alwways set the output in the same (interlaced) resolution as the broadast, NOT in the TV's native resolution. And no vertical scaling is allowed before deinterlacing! (but horizontal is allowed)
Someone correct me if I'm wrong
What I'd hope happen (for interlaced material) is that xine receives a field from VDR, scales it to the X resolution (halfed vertically of course) and sends it to the the graphics card which just passes it on to the TV which draws that field. That doesn't seem to happen so where have I gone wrong?
In changing the resolution. To achieve what you want, you need to set X to a PAL modeline (720 x 576 interlaced for PAL). However, this is not as straightforward for a VGA card as for full featured DVB cards or set tob boxes. Even after setting the right modeline, a few problems remain:
1) You need to enable sync on vblanck.
2) There is no way to automatically switch the resolution when/if the standard changes
3) The timigns are not exact on VGA (HDMI etc.) outputs
The first is not possible on all drivers (i.e. fglrx). For the second problem there are no ready made solutions (but you can of course manually change between modes, and perhaps restart some sowftware when needed). For the third problem, see thread "RGB/PAL over VGA at variable frame rate" for more discussion and patches.
Someone correct me if I'm wrong.
On Tue, 20 Jan 2009 18:19:49 +0200 "Ville Aakko" ville.aakko@gmail.com wrote:
- You need to enable sync on vblanck.
[Snip]
The first is not possible on all drivers (i.e. fglrx).
Absolutely not possible? I know OpenGL, DRI and NVidia drivers all have APIs for waiting for vblank and ISTR seeing a xine option for vblank sync with Xv. Do none of these work with fglrx? Nvidia's settings tool has options to disable vblank sync for OpenGL and video, but I don't know whether by setting it off it disables syncing altogether or by setting it on it forces flip operations to automatically wait for vblank.
Another problem is that in interlaced modes on standard graphics cards you get a vblank interrupt for each field with no way of distinguishing between top or bottom fields; getting them the wrong way round is really messy! Certain Matrox cards let applications distinguish between top and bottom fields, but it's only (officially) supported on the TV-out (SDTV) on the second head using DirectFB.
2009/1/20 Tony Houghton h@realh.co.uk:
On Tue, 20 Jan 2009 18:19:49 +0200 "Ville Aakko" ville.aakko@gmail.com wrote:
- You need to enable sync on vblanck.
[Snip]
The first is not possible on all drivers (i.e. fglrx).
Absolutely not possible? I know OpenGL, DRI and NVidia drivers all have APIs for waiting for vblank and ISTR seeing a xine option for vblank sync with Xv. Do none of these work with fglrx? Nvidia's settings tool has options to disable vblank sync for OpenGL and video, but I don't know whether by setting it off it disables syncing altogether or by setting it on it forces flip operations to automatically wait for vblank.
AFAIK this is a known issue with fglrx drivers. The API is there, but with fglrx the detection is (currently) broken, at least on 8.11 (which is what I'm using currently). I think I saw someone in some forum getting vsync working with fglrx but only for 'mplayer -vo gl'. But that was an exception-
On Mon, Jan 19, 2009 at 09:54:18PM +0000, Scott Waye wrote:
I want to replace my UK Sky digital box with VDR (I only want the free to air channels) for watching/recording TV over HDMI on my plasma. So far everything is working OK, I have vdr 1.7.3 and xine running on an ASUS M2N VM-HDMI (nvidia) mobo with the s2-liplianin drivers for my Nova SD2 card. My problem is interlacing. I've googled back through the archives and got a lot of info from there, however I still have one question and one request.
If X is put into an interlaced mode (1920x1080i @ 50Hz), and I do not do any de interlacing in xine, why is this not the same as what my digibox does? I'm guessing it has something to do with xine outputting a complete frame when the broadcast sends each field? What I'd hope happen (for interlaced material) is that xine receives a field from VDR, scales it to the X resolution (halfed vertically of course) and sends it to the the graphics card which just passes it on to the TV which draws that field. That doesn't seem to happen so where have I gone wrong?
There's a lot of options for tvtime in xine, TomsMoComp and full framerate seem popular. What settings are others using?
Hello.
Please check this thread: http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html
Original patches: http://lowbyte.de/vga-sync-fields/
New version: http://www.vdr-portal.de/board/thread.php?threadid=80567
Those might help.. they're about getting pure 1:1 interlaced (576i) RGB output from a VGA card.. and the new version also has some HDTV stuff, I guess. I don't read german so i'm not familiar with that..
There are also patches to maintain perfect field sync to DVB stream to avoid tearing/stutter/jerkiness.
-- Pasi
On Tue, 20 Jan 2009 18:23:21 +0200 Pasi Kärkkäinen pasik@iki.fi wrote:
Please check this thread: http://www.linuxtv.org/pipermail/vdr/2008-July/017347.html
Original patches: http://lowbyte.de/vga-sync-fields/
New version: http://www.vdr-portal.de/board/thread.php?threadid=80567
Those might help.. they're about getting pure 1:1 interlaced (576i) RGB output from a VGA card.. and the new version also has some HDTV stuff, I guess. I don't read german so i'm not familiar with that..
There are also patches to maintain perfect field sync to DVB stream to avoid tearing/stutter/jerkiness.
Varying the output frame rate to keep in sync with the input stream is very clever, but I don't understand how it solves the problem of distinguishing between top and bottom fields to sync to.
On Tue, Jan 20, 2009 at 05:21:53PM +0000, Tony Houghton wrote:
Varying the output frame rate to keep in sync with the input stream is very clever, but I don't understand how it solves the problem of distinguishing between top and bottom fields to sync to.
surely you can distinguish top and bottom fields on older (pre-avivo) Radeon cards. My vga-sync-fields patch exactly uses this feature:
---8<--- #define RADEON_CRTC_STATUS 0x005c #define RADEON_CRTC_CURRENT_FIELD (1 << 3)
field = INREG(RADEON_CRTC_STATUS) & RADEON_CRTC_CURRENT_FIELD; ---8<---
BTW: I meanwhile could port the Radeon VGA2SCART thing to Intel i9xx chipsets too. Description of my Intel patch can be found here (sorry only in German):
patch version I: http://www.vdr-portal.de/board/thread.php?postid=766459#post766459
patch version II: http://www.vdr-portal.de/board/thread.php?postid=769703#post769703
For Intel chipsets you even don't have to tamper with kernel modules like radeon-drm since they already have builtin some key features needed for VGA2SCART frame rate control.
This way you now can build very cheap budget VDRs based on modern hardware like Intel D945GCLF/D945GCLF2 or Pundit P5945GC. With SCART output quality equaling a FF card but at fractional cost.
As with former Radeon vga-sync-fields patch even/odd fields are routed straightly from softdecoder to VGA port. No software deinterlacing takes place thus saving CPU power and resulting in an artifact free picture.
All you additionally need is a special VGA2SCART adapter cable like this:
http://www.vdr-portal.de/board/thread.php?postid=742945#post742945
Because VGA2SCART patches now appear to become more popular in this FF dominated VDR-world:-) VDR distribution easy-vdr just started to integrate Radeon and Intel VGA2SCART patches for everyone use. Please see also
http://www.easy-vdr.de/forum/index.php?board=63.0
It seems German related sites show more interest in VGA2SCART things. So I did not spend further time to translate all things I developed for VGA2SCART into english. Sorry for that;-)
Due to -ENOTIME I have not yet integrated my last Intel patches to vga-sync-fields patch version found at
http://lowbyte.de/vga-sync-fields/
Cheers Thomas
On 21 Jan 2009, at 15:02, Thomas Hilber wrote:
This way you now can build very cheap budget VDRs based on modern hardware like Intel D945GCLF/D945GCLF2 or Pundit P5945GC. With SCART output quality equaling a FF card but at fractional cost.
Does it work with 915 hardware as well?
On Wed, Jan 21, 2009 at 03:22:15PM +1000, Torgeir Veimo wrote:
Does it work with 915 hardware as well?
Yup, a few days ago I successfully testet the patch on my Asus EEE 701. Even replaying interlaced SD content the 900MHz CPU idles at about 60%. Please see table at
http://www.vdr-portal.de/board/thread.php?postid=784548#post784548
It appears that most of recent Intel based (i9xx graphics) netbooks are suitable for VGA2SCART with frame rate control (synced fields).
A complete list of VGA2SCART capable chipsets is under contruction here:
http://www.vdr-portal.de/board/thread.php?postid=782181#post782181
legend: a '+' in 'PAL' column means: unsynced (with software deinterlacing) VGA2SCART is possible.
a '+' in 'FRC' column means: synced (i.e. frame rate control obsoleting software deinterlacing) VGA2SCART is possible.
On 21 Jan 2009, at 16:17, Thomas Hilber wrote:
On Wed, Jan 21, 2009 at 03:22:15PM +1000, Torgeir Veimo wrote:
Does it work with 915 hardware as well?
Yup, a few days ago I successfully testet the patch on my Asus EEE 701. Even replaying interlaced SD content the 900MHz CPU idles at about 60%. Please see table at
http://www.vdr-portal.de/board/thread.php?postid=784548#post784548
It appears that most of recent Intel based (i9xx graphics) netbooks are suitable for VGA2SCART with frame rate control (synced fields).
A complete list of VGA2SCART capable chipsets is under contruction here:
http://www.vdr-portal.de/board/thread.php?postid=782181#post782181
legend: a '+' in 'PAL' column means: unsynced (with software deinterlacing) VGA2SCART is possible.
a '+' in 'FRC' column means: synced (i.e. frame rate control obsoleting software deinterlacing) VGA2SCART is possible.
Ok, I have this hardware; http://www.silentpcreview.com/article311-page1.html an asus mainboard i915ga-hfs, with 915G graphics and onboard YPbPr and DVI outputs. I figure with some tweaking, it should be possible to run pure RGB or YPbPr out without using any vga to scart adapter.
There's no english howto anywhere?
On Wed, Jan 21, 2009 at 04:23:59PM +1000, Torgeir Veimo wrote:
Ok, I have this hardware; http://www.silentpcreview.com/article311-page1.html an asus mainboard i915ga-hfs, with 915G graphics and onboard YPbPr and DVI outputs. I figure with some tweaking, it should be possible to run pure RGB or YPbPr out without using any vga to scart adapter.
yeah! I guess you even could run interlaced HDMI (with a DVI to HDMI adaptor) with synced fields using that hardware. This would be especially useful for HDTV applications as software deinterlacing there is a real pain.
On german vdr-portal 'durchflieger' already published some working configurations with synced fields (frame rate control) over HDMI. The radeon-frc patch README and description is written in English. Please refer to:
http://www.vdr-portal.de/board/thread.php?threadid=80567
There's no english howto anywhere?
sorry, not yet.
Thomas Hilber a écrit :
On Wed, Jan 21, 2009 at 04:23:59PM +1000, Torgeir Veimo wrote:
There's no english howto anywhere?
sorry, not yet.
Is the below rough summary correct ?
What it currently is : * a patch set to DRM kernel modules, xine-lib and xineliboutput * that adds proper interlaced output from ATI and Intel GPUs * it also adds FrameRateControl under some conditions * it's stable and works on VGA, but seems to also work on HDMI * only works with Xv (does/can not make use of XvMC) * can work with any display device (CRT, LCD, plasma) * make most use of the display device capability (interlaced display on a SD CRT, "picture enhancers" on HD LCD/Plasma)
Ideal goal would probably imply : * output mode change upon source mode change (output 720x576i on the VGA when playing SDTV, output 1920x1080i/p when playing HDTV contents, etc.) * make use of hardware decoding capabilities when available (specially for HDTV)
Side-needs : * add support for nVidia, VIA chips, etc. (feasability ?) * integrate these patches upstream (feasability, propagation delays?)
On Wed, Jan 21, 2009 at 12:55:19PM +0100, Nicolas Huillard wrote:
Is the below rough summary correct ?
What it currently is :
- a patch set to DRM kernel modules, xine-lib and xineliboutput
...not to forget the Xserver-DDX (hardware specific module) itself.
For pre-avivo Radeons you need to patch in all four areas. For Intel i9xx chips patches in DRM kernel modules are obsolete since certain functionality is already implemented in graphics hardware.
- that adds proper interlaced output from ATI and Intel GPUs
right
- it also adds FrameRateControl under some conditions
yes. For pre-avivo Radeons and i9xx Intels FrameRateControl is possible
- it's stable and works on VGA, but seems to also work on HDMI
for some people at vdr-portal and me it already works stable:-) Compared to a FF card WSS is not yet implemented for Radeons. You currently must use one of the available SCART Pin 8 solutions there.
Intel graphics allow hardware scaling in Y dimension even in interlaced mode (if needed). So WSS is obsolete there.
Still lacking an HDMI capable device I mainly focused on VGA/SCART output method. But also some working configurations already exist with FrameRateControl over HDMI. Please see link to 'durchfliegers' thread above.
- only works with Xv (does/can not make use of XvMC)
currently it only works with Xv since this is the lowest common denominator for video things under X available as open source. I don't think MPEG2 decoding is worth all the effort to implement that in firmware. Even on very slow processors MPEG2 decoding alone (with NO deinterlacing) is running sufficiently fast.
- can work with any display device (CRT, LCD, plasma)
should work with most VGA or SCART capable display devices. I tested with several CRT-SCART-TVs and LCD-SCART-TVs and experienced no problems yet.
Some other people also could successfully rebuild the system.
- make most use of the display device capability (interlaced display on
a SD CRT, "picture enhancers" on HD LCD/Plasma)
that's the main intention behind the idea. At least it should relieve the software of deinterlacing because todays PC architectures still can't do that efficiently by means of the main CPU.
Ideal goal would probably imply :
- output mode change upon source mode change (output 720x576i on the VGA
when playing SDTV, output 1920x1080i/p when playing HDTV contents, etc.)
this interesting theme has already been addressed by 'durchflieger' from vdr-portal. I even think Petri has adopted some parts of durchflieger's patch for xineliboutput. But I don't know exactly. Thread:
http://www.vdr-portal.de/board/thread.php?threadid=80573
- make use of hardware decoding capabilities when available (specially
for HDTV)
for HDTV use of hardware decoding capabilities are a future goal. For SDTV as already mentioned I don't think it's worth the additional effort. I never understood all these discussing about MPEG2 decoding in hardware/firmware. Even low end machines as SMT7020 decode with CPU with no problems.
Side-needs :
- add support for nVidia, VIA chips, etc. (feasability ?)
most nVidia chips are VGA2SCART capable out-of-the-box even with recent open source Xserver-DDX. I threw a quick glance at this a few weeks ago.
As specifications are not available for nVidia chips there is no way to implement FrameRateControl there. So VGA2SCART provides no special benefits for nVidia chips except that you drive an real 50Hz-capable (PAL) device.
I never dealt with VIA chips so far.
- integrate these patches upstream (feasability, propagation delays?)
although ATI and Intel Xorg developers always kindly answered my questions they seem not to be very interested in abusing a VGA port for SCART. Even simple interlaced modelines are often not supported yet without additional patches.
Current upstream development mainly focuses on conventional TV-out ports. Probably because todays graphics hardware is not directly designed with VGA2SCART in mind. Not to mention VGA2SCART+FrameRateControl which can only be achieved by playing some tricks.
I think special VDR distributions like easy-vdr currently are the only means to make the patches available to everyone in a convenient way.
- Thomas
On Wed, Jan 21, 2009 at 06:02:23AM +0100, Thomas Hilber wrote:
It seems German related sites show more interest in VGA2SCART things. So I did not spend further time to translate all things I developed for VGA2SCART into english. Sorry for that;-)
I think there's demand for this functionality all over the world :) not just in germany.
I think someone should step ahead and help with the english docs.. unfortunately I can't do that atm, too busy with other things..
-- Pasi
On Wed, 21 Jan 2009 17:07:40 +0200 Pasi Kärkkäinen pasik@iki.fi wrote:
On Wed, Jan 21, 2009 at 06:02:23AM +0100, Thomas Hilber wrote:
It seems German related sites show more interest in VGA2SCART things. So I did not spend further time to translate all things I developed for VGA2SCART into english. Sorry for that;-)
I think there's demand for this functionality all over the world :) not just in germany.
I think someone should step ahead and help with the english docs.. unfortunately I can't do that atm, too busy with other things..
It is excellent, but I can't help thinking it's come a bit too late. CRTs and SCART are being replaced by LCD and HDMI, and given an interlaced picture, an LCD has to deinterlace it rather than take advantage of phosphor decay. In theory a decoder such as VDPAU can deinterlace better than the TV because it has access to extra info such as motion vectors in the MPEG.
On Wed, Jan 21, 2009 at 04:03:37PM +0000, Tony Houghton wrote:
It is excellent, but I can't help thinking it's come a bit too late.
not if it comes to HDTV. Basically it should be feasible to recycle some of the ideas there.
BTW I wanted to prove that simple graphics hardware together with low end processors are capable to provide the same picture quality as do those cumbersome FF cards. But at much lower cost besides many other advantages. Unfortunately nobody cared about developing alternatives to FF cards the past years.
advantage of phosphor decay. In theory a decoder such as VDPAU can deinterlace better than the TV because it has access to extra info such as motion vectors in the MPEG.
you certainly are right with this but VDPAU is no open source. Maybe some day FrameRateControl will allow for a pure open source HDTV solution. Running with adequate picture quality on moderately powered CPUs.
- Thomas
On Wed, 21 Jan 2009 18:35:00 +0100 Thomas Hilber vdr@toh.cx wrote:
Maybe some day FrameRateControl will allow for a pure open source HDTV solution. Running with adequate picture quality on moderately powered CPUs.
Yes, hopefully one day Intel will have a fully operational VA or something, including MPEG 4, and include HDMI or DVI on the motherboard instead of having an adaptor taking up a valuable PCI-e slot.
I wouldn't consider FrameRateControl absolutely vital, playback of live TV is smooth enough without it IME, but ironically libxine seems better at playing live TV than VDR recordings which always seem to me to suffer more frame jumps, loss of AV sync and pops in the sound than live TV.
When playing back recordings it doesn't matter if the video output frame rate isn't quite right, you can avoid dropping or repeating frames by resampling the audio if sync starts to drift - this appears to be an option in xine's config, but it doesn't seem to work correctly on recordings for me.
I already sometimes use resampling in mplayer to watch 24fps videos smoothly at 25fps and the sound quality is still subjectively OK - certainly less intrusive in the overall "experience" than jumping video frames.
Thomas Hilber vdr@toh.cx wrote:
Maybe some day FrameRateControl will allow for a pure open source HDTV solution. Running with adequate picture quality on moderately powered CPUs.
I think it is very important for HDTV without any other solution. One of my main reasons for buying a eHD was that whilst xine / coreavc was great for watching films (progressive source) etc, it was not good for watching sport (interlaced source) and even with a Core2 Duo 3Ghz enabling good interlacing (tvtime) resulted in the processor becoming bound and huge amount of frame drops.
Taking this problem out of the equation would be a big help.
On Wed, Jan 21, 2009 at 05:07:40PM +0200, Pasi Kärkkäinen wrote:
I think someone should step ahead and help with the english docs.. unfortunately I can't do that atm, too busy with other things..
after travelling over 5 weeks in Australia this now is my major problem too:-)
Dear Thomas and fellow developers,
Am Mittwoch, den 21.01.2009, 17:42 +0100 schrieb Thomas Hilber:
On Wed, Jan 21, 2009 at 05:07:40PM +0200, Pasi Kärkkäinen wrote:
I think someone should step ahead and help with the english docs.. unfortunately I can't do that atm, too busy with other things..
after travelling over 5 weeks in Australia this now is my major problem too:-)
Is there a homepage for the VGA2SCART patch set with information about it? A repository?
There seems to be some interest from people outside VDR Portal [1] in the patches. So a repository with all the different branches (for example yours and durchfliegers) could be used to manage the files. Would a Wiki page be useful or is the README enough?
Have you already thought about this and came to the conclusion it is not necessary?
Or could one ask the project your patches are related to, if they could set up a branch for each of the patches and the information is managed in a Wiki like VDR Wiki [2] or the one of Freedesktop [3]?
Thanks,
Paul
[1] www.vdr-portal.de [2] http://www.vdr-wiki.de/wiki/index.php/Hauptseite [3] http://www.freedesktop.org/wiki/
On Wed, Feb 25, 2009 at 01:35:01PM +0100, Paul Menzel wrote:
Is there a homepage for the VGA2SCART patch set with information about it? A repository?
due to lack of time and interest I do not yet run a full blown homepage. But at least I started to collect the plain patches here [3].
There seems to be some interest from people outside VDR Portal [1] in the patches. So a repository with all the different branches (for example yours and durchfliegers) could be used to manage the files. Would a Wiki page be useful or is the README enough?
Surely a Wiki page could be useful. Not only for special frame rate control (FRC) patches. Also for VGA2SCART in general. This site should be run in English. But in the past the most interest in the patches has been shown by german users. That's why I payed more attention to them.
BTW: Markus "Mahlzeit" Küchler already started a german Wiki [2]
Or could one ask the project your patches are related to, if they could set up a branch for each of the patches and the information is managed in a Wiki like VDR Wiki [2] or the one of Freedesktop [3]?
there is no 'project' my patches are related to. I just wondered why people often are complaining about non smooth playback on graphics cards. On the other hand there is NO official implementation for synchronization between stream and VGA timing until today. Neither for SD nor for HD.
So I just started to solve the problem for my own purposes. That's how it begun.
I think there are 2 viable ways to distribute the patches:
1.) by generic instructions how to build the system (i.e. a big README) 2.) by some ready-to-use VDR distribution
The FRC patches take into account the entire PC. All software components (kernel, xserver, softdecoder) involved must fit together exactly.
Finally I decided in favor of 2.) and I started to help to integrate the patches into easy-vdr.de [1] distribution.
BTW: this work for me is more interesting than to write documentation about how to install the patches:-)
You now can simply download+install an easy-vdr based system. After this you will have a working system out-of-the-box with VGA2SCART + FRC.
Successfully tested on D945GCLF and Pundit P1-P5945GC and some other Intel i9xx based boxes. ATI Radeon type systems are not yet included there.
Cheers Thomas
[1] http://www.easy-vdr.de/forum/index.php?topic=6072.msg51320#msg51320 [2] http://vdr-wiki.de/wiki/index.php/CheapBudget [3] http://lowbyte.de/vga-sync-fields/
Dear Thomas,
thanks for your answer.
Am Mittwoch, den 25.02.2009, 15:49 +0100 schrieb Thomas Hilber:
On Wed, Feb 25, 2009 at 01:35:01PM +0100, Paul Menzel wrote:
Is there a homepage for the VGA2SCART patch set with information about it? A repository?
due to lack of time and interest I do not yet run a full blown homepage. But at least I started to collect the plain patches here [3].
That is what I thought. So maybe other people who are not good or intersted in coding could help set up this web site and repository. Would you be willing to use this. Do you have a favorite system for SCM (Git, Subversion, …)?
@Tobi: Could the patches be hosted on projects.vdr-developers.org?
Thanks,
Paul
On Thu, Feb 26, 2009 at 09:12:36AM +0100, Paul Menzel wrote:
due to lack of time and interest I do not yet run a full blown homepage. But at least I started to collect the plain patches here [3].
That is what I thought. So maybe other people who are not good or intersted in coding could help set up this web site and repository. Would you be willing to use this. Do you have a favorite system for SCM
At least somebody must start such a page..
For the moment it takes less time for me to answer questions in the corresponding threads on easy-vdr.de and vdr-portal.de directly.
Why don't you just use the easy-vdr install script I mentioned above which already has been proven successful?
If you are interested in what's happening behind the scenes - no problem. The script builds all VGA2SCART + FRC relevant things from source.
There is no better way to document an installation than a working shell script:-)
Cheers Thomas
Am Donnerstag, den 26.02.2009, 19:47 +0100 schrieb Thomas Hilber:
On Thu, Feb 26, 2009 at 09:12:36AM +0100, Paul Menzel wrote:
due to lack of time and interest I do not yet run a full blown homepage. But at least I started to collect the plain patches here [3].
That is what I thought. So maybe other people who are not good or intersted in coding could help set up this web site and repository. Would you be willing to use this. Do you have a favorite system for SCM
At least somebody must start such a page..
For the moment it takes less time for me to answer questions in the corresponding threads on easy-vdr.de and vdr-portal.de directly.
I would be willing to begin to start such a page. But I wanted to know your preferences, so that chances are high, that you will feel comfortable with it.
I will ask the owners of projects.vdr-developers.org again.
Why don't you just use the easy-vdr install script I mentioned above which already has been proven successful?
I just checked it out. But the main problem in distribution is, that everyone has to register to be able to download attachments.
If you are interested in what's happening behind the scenes - no problem. The script builds all VGA2SCART + FRC relevant things from source.
I just took a look. On quick look at the homepage and the Wiki I could not find any information on [1] on what Easy VDR does and on what distro it is based.
Looking at the script it looks like it is based on Debian Etch.
There is no better way to document an installation than a working shell script:-)
Of course, but if one has to register at a forum to get the files it will prevent people from getting it and to contributing to the project. That is why I think a repository would be helpful. Then everything relating to the code would be in one place and work does not have to be done twice because one did not see that thread were someone else already implemented this.
I find it very difficult to jump through all the threads of the forum and reads through all the posts and most of the time read it several times.
Thanks a lot,
Paul
On Sat, Feb 28, 2009 at 08:04:17PM +0100, Paul Menzel wrote:
Why don't you just use the easy-vdr install script I mentioned above which already has been proven successful?
I just checked it out. But the main problem in distribution is, that everyone has to register to be able to download attachments.
what's wrong with it? If registering is too much effort - nothing doing.
I just took a look. On quick look at the homepage and the Wiki I could not find any information on [1] on what Easy VDR does and on what distro it is based.
Looking at the script it looks like it is based on Debian Etch.
it's a complete VDR distribution based on debian etch.
There is no better way to document an installation than a working shell script:-)
Of course, but if one has to register at a forum to get the files it will prevent people from getting it and to contributing to the project.
but it will guarantee to a certain extend that you will obtain a tested and working setup out-of-the-box after installation has finished.
I would be willing to begin to start such a page. But I wanted to know your preferences, so that chances are high, that you will feel comfortable with it.
the problem is you can write whole books about the VGA2SCART theme. I *certainly* won't have the time to do that. But for the beginning I could post a plain list of URLs where I finally got my informations from.
- Thomas
Am Sonntag, den 01.03.2009, 07:40 +0100 schrieb Thomas Hilber:
On Sat, Feb 28, 2009 at 08:04:17PM +0100, Paul Menzel wrote:
Why don't you just use the easy-vdr install script I mentioned above which already has been proven successful?
I just checked it out. But the main problem in distribution is, that everyone has to register to be able to download attachments.
what's wrong with it? If registering is too much effort - nothing doing.
Well, it is just cumbersome.
0. Having this kind of file list takes less time and you can use wget for example. 1. It takes time to register. 2. Being a German speaking forum, non-German speaker will not register just to download something. 3. You have to give an e-mail address and remember a password.
(I do not like forums for this reason. If I want to take a look at an attachment the post refers to I have to register. I do not think it is appropriate to register at every forum. …)
I just took a look. On quick look at the homepage and the Wiki I could not find any information on [1] on what Easy VDR does and on what distro it is based.
Looking at the script it looks like it is based on Debian Etch.
it's a complete VDR distribution based on debian etch.
Lenny is out! ;-)
There is no better way to document an installation than a working shell script:-)
Of course, but if one has to register at a forum to get the files it will prevent people from getting it and to contributing to the project.
but it will guarantee to a certain extend that you will obtain a tested and working setup out-of-the-box after installation has finished.
I agree that it is a good way for a lot of people. But I believe it takes some freedom of choices away from the people, which want to have your latest patches to play with them and test them. I think those people are also potential contributors.
I would be willing to begin to start such a page. But I wanted to know your preferences, so that chances are high, that you will feel comfortable with it.
the problem is you can write whole books about the VGA2SCART theme. I *certainly* won't have the time to do that.
I know. And therefore I hope other people can do this. But to get going one still has to communicate and organize a little to go into the same direction.
But for the beginning I could post a plain list of URLs where I finally got my informations from.
Well, that would certainly be interesting but I think not the most important thing.
My Proposal ===========
Ok to start something I just did a test setup [2] of ikiwiki [3]. That is just an example for what I think could be done to improve the visibility of VGA2SCART to the world. ;-)
So if you do not like it or if you have another idea, I proceed as you like, Thomas.
Reading your README I assume you are familiar with Git. Therefore I choose it as a backend.
To clone it you can use.
git clone git://vga2scart.gw90.de/git/vga2scart
Notes -----
Some notes about all this. ikiwiki takes formatted text files (standard is Markdown) and based on them creates HTML pages. Using a repository and a post-commit-hook the Wiki is updated every time something is checked into the Wiki.
The author of ikiwiki, Joey Hess, wrote about this development model [4].
More a less it does not change a lot, because instead of writing something into the README you structure it a little bit more and use a formatting style (you already used something like this in your README) and ikiwiki builds a website additionally.
You could take a look on how ikiwiki is used in reality at ikiwiki [3] or for example Monkeysphere [5]. ikiwiki is keeping the documentation with the wiki under doc/ [6]. Monkeysphere does not use ikiwiki as a wiki for normal users, but the developers use it to present their project.
I must admit that a user has to register to edit the Wiki either using his OpenID (only version 1 supported) creating an account. But anonymous commits can be allowed by a plugin.
I did not put more work into the content of the pages not knowing what you think. But as the nature of a wiki it will hopefully transform into a good documentation about the project.
Continue --------
I guess, you are using source code management doing creating your patches. An easy way would be, if you could publish your tree(s) so that it is accessible from the web. Then you could create a folder doc, where the wiki is build from.
If you want to host this on your infrastructure that would be perfect. If others can help you providing infrastructure that is also fine.
What do you think?
Thanks,
Paul
PS: Sorry, if my message is a little confusing. I hope I did not forget anything.
[1] http://lowbyte.de/vga-sync-fields/ [2] http://vga2scart.gw90.de/ [3] http://ikiwiki.info/ [4] http://www.linuxworld.com/news/2007/040607-integrated-issue-tracking-ikiwiki... [5] http://web.monkeysphere.info/ [6] http://git.ikiwiki.info/?p=ikiwiki;a=tree;f=doc;h=e80f117941cf1f3cc5815bdde2...
On Sun, Mar 01, 2009 at 06:43:00PM +0100, Paul Menzel wrote:
Reading your README I assume you are familiar with Git. Therefore I choose it as a backend.
Thank you for your effort so far.
I have no special preferences here. GIT or CVS is ok for me.
Concerning the wiki: I would prefer a neutral domain or even better
for this. IMHO all VDR related documentation and discussion should be collected at one place. 'Hosting' the source is another issue. We could use sourceforge.net for this?
- Thomas
Am Montag, den 02.03.2009, 12:52 +0100 schrieb Thomas Hilber:
On Sun, Mar 01, 2009 at 06:43:00PM +0100, Paul Menzel wrote:
Reading your README I assume you are familiar with Git. Therefore I choose it as a backend.
Thank you for your effort so far.
No problem. I guess you have done more so far.
I have no special preferences here. GIT or CVS is ok for me.
Concerning the wiki: I would prefer a neutral domain
Sure. I had no other domain handy. Your domain name could also be used, if you set up DNS this way (vga2scart.lowbyte.de) or we register some free domain name vga2scart.de.vu or vga2scart.eu.org?
or even better
for this.
If you are fine with that, great. My reasoning choosing ikiwiki is, that I would expect it to save you (and others) time.
1. Everyone can use his favorite text editor and saves time not having to open a browser and use web forms.
2. Let us say, you implement support for another card(?), than you would update the README right away using the console and your editor of choice and the Wiki is updated, too. Otherwise you would have to log into http://www.linuxtv.org/wiki/ find the page, hit edit, (wait for it to load,), …
Do you care about this? It all depends on your needs and habits.
On a side note. Do you know if linuxtv.org is also for non-English languages. In my opinion, it would not be so beneficial to have the documentation for one language on one site and for another language on another.
IMHO all VDR related documentation and discussion should be collected at one place.
Is linuxtv.org the place for VDR related documentation?
Do you mean by discussion mailing lists?
'Hosting' the source is another issue. We could use sourceforge.net for this?
I never used sourceforge.net. So I can not say anything about this. They offer SVN and CVS, do not they?
My conclusion from your reply is, that publishing your repository on your server is not an option.
Could you please tell me, how you are managing the VGA2SCART patches right now and if publishing your tree on a server or for example [1] would be an option.
Thanks,
Paul
On Mon, Mar 02, 2009 at 01:19:53PM +0100, Paul Menzel wrote:
Concerning the wiki: I would prefer a neutral domain
Sure. I had no other domain handy. Your domain name could also be used, if you set up DNS this way (vga2scart.lowbyte.de) or we register some free domain name vga2scart.de.vu or vga2scart.eu.org?
something like vga2scart.eu.org sounds good. Though our project is not limited to vga2scart. In the meantime I successfully use a modified version of the vga-sync-fields patch on DVI/HDMI interface also. Providing me high quality 576i over DVI/HDMI on intel i9xx machines with SDVO ports. Originating from SDTV our project could be important for HDTV also.
or even better
for this.
If you are fine with that, great. My reasoning choosing ikiwiki is, that I would expect it to save you (and others) time.
I wonder why nobody else joins our discussion.
Just to clarify: My major goal was to prove that graphics cards can provide the same picture quality as FF-cards do. But with wider flexibility at fractional cost of a FF-card among many other advantages. And without the need of expensive and time consuming hardware mods like full-TS mod, AV-board, J2 mod etc.
We now have a working sample installation for a budget system with FRC based on easy-vdr [4] which has been successfully setup by various people. Reaching this stage I consider my 'mission' completed.
You can setup a repos with current source found in vga-sync-fields package at anytime. Everybody is invited to test and contribute. I don't consider it as 'my' project. I just will contribute the initial idea behind frame rate control and a sample implementation for it.
And of course I will continue to develop as time permits.
- Everyone can use his favorite text editor and saves time not having
to open a browser and use web forms.
- Let us say, you implement support for another card(?), than you would
update the README right away using the console and your editor of choice and the Wiki is updated, too. Otherwise you would have to log into http://www.linuxtv.org/wiki/ find the page, hit edit, (wait for it to load,), ???
ok, I wouldn't bother much to log in. It depends on what the majority of possible contributers would prefer.
Do you care about this? It all depends on your needs and habits.
no.
On a side note. Do you know if linuxtv.org is also for non-English languages. In my opinion, it would not be so beneficial to have the documentation for one language on one site and for another language on another.
I don't know. But I think an english doc should be enough.
IMHO all VDR related documentation and discussion should be collected at one place.
Is linuxtv.org the place for VDR related documentation?
At least they have a wiki. The German VDR wiki [1] refers to [2] when you select the english language button.
Do you mean by discussion mailing lists?
right.
I never used sourceforge.net. So I can not say anything about this. They offer SVN and CVS, do not they?
sorry, I can't tell
My conclusion from your reply is, that publishing your repository on your server is not an option.
unfortunately it's not an option ATM
Could you please tell me, how you are managing the VGA2SCART patches right now and if publishing your tree on a server or for example [1] would be an option.
'gitorious.org' appears ok for me. As I worked alone yet on this project I did not use any source code control system until now.
As said, I don't consider it as my project. Everybody is invited to improve the project status. There are left many ideas and features still not implemented. I already wrote a to-do list with issues of lesser priority. But features that would improve things a lot.
- like writing a tool similar to powerstrip. Which lets you adjust overscan and other parameters in real time by pressing cursor keys. or
- derive xine's masterclock from graphics card frame rate. This would provide almost instant sync after a channel switch. The idea for this was published by 'durchflieger' [3]
There are still left many things to do. As often in life it's not a matter of ideas but a matter of time:)
Cheers Thomas
[1] http://vdr-wiki.de/wiki/index.php/Hauptseite [2] http://www.linuxtv.org/vdrwiki [3] http://www.vdr-portal.de/board/thread.php?postid=796538#post796538 [4] http://www.easy-vdr.de/forum/index.php?topic=6072.msg51320#msg51320
Am Montag, den 02.03.2009, 17:26 +0100 schrieb Thomas Hilber:
On Mon, Mar 02, 2009 at 01:19:53PM +0100, Paul Menzel wrote:
Concerning the wiki: I would prefer a neutral domain
Sure. I had no other domain handy. Your domain name could also be used, if you set up DNS this way (vga2scart.lowbyte.de) or we register some free domain name vga2scart.de.vu or vga2scart.eu.org?
something like vga2scart.eu.org sounds good. Though our project is not limited to vga2scart. In the meantime I successfully use a modified version of the vga-sync-fields patch on DVI/HDMI interface also. Providing me high quality 576i over DVI/HDMI on intel i9xx machines with SDVO ports. Originating from SDTV our project could be important for HDTV also.
Everyone, could please brainstorm about a name for this project [5].
or even better
for this.
If you are fine with that, great. My reasoning choosing ikiwiki is, that I would expect it to save you (and others) time.
I wonder why nobody else joins our discussion.
[…]
You can setup a repos with current source found in vga-sync-fields package at anytime. Everybody is invited to test and contribute. I don't consider it as 'my' project. I just will contribute the initial idea behind frame rate control and a sample implementation for it.
And of course I will continue to develop as time permits.
[…]
As said, I don't consider it as my project. Everybody is invited to improve the project status. There are left many ideas and features still not implemented.
As written in my other message I continued to set up ikiwiki for the project [5]. If something else will be better for the project, please say so and we can change that.
I consider the most important thing right to get someone to publish detailed instruction on how a VGA2SCART cable can be assembled.
For me a circuit diagram is not good enough for an inexperienced user in soldering as myself. (Do I attach/fix the resistors on a board or just between the wires? Where can I get the parts? …)
I already wrote a to-do list with issues of lesser priority. But features that would improve things a lot.
- like writing a tool similar to powerstrip. Which lets you adjust overscan
and other parameters in real time by pressing cursor keys. or
- derive xine's masterclock from graphics card frame rate. This would
provide almost instant sync after a channel switch. The idea for this was published by 'durchflieger' [3]
There are still left many things to do. As often in life it's not a matter of ideas but a matter of time:)
I added those two to the TODO list of the website [6].
Thanks,
Paul
[1] http://vdr-wiki.de/wiki/index.php/Hauptseite [2] http://www.linuxtv.org/vdrwiki [3] http://www.vdr-portal.de/board/thread.php?postid=796538#post796538 [4] http://www.easy-vdr.de/forum/index.php?topic=6072.msg51320#msg51320
[5] http://vga2scart.gw90.de/ [6] http://vga2scart.gw90.de/todo/
First, I don't know why, but everyone of your post comes through as a text attachment which has to be saved out to be read. Others on the list come through normal.
When puting just a few parts in a connector I try to solder the parts directly to the pins on the back of the connector in a way that allows the shell to still fit. If there are too many parts or wires that need to be connect to allow this and still keep the parts ridged, then a small perf board should be used. In eather case, make use of very small heat swrink to prevent shorts.
I also use hot melt glue to hold parts and wires in place and reduce strain. If the factory shell can not be used, then I mold the area with hot melt. Once you have a solid mass that covers all bare wires, you can shape i with a soldering iron. With very little practice you can smooth the glue to look like it was molded on. Then heat swrink tubing can be used to cover it and make it look nice. If you have a soldering iron with adjustable temp, keep it low for shaping. If you latter need to work on it, you can remove the glue with a dental pick with a bit of work.
----- Original Message ----- From: "Paul Menzel" paulepanter@users.sourceforge.net To: vdr@linuxtv.org Sent: Wednesday, March 04, 2009 10:32 AM Subject: Re: [vdr] [OT] development infrastructur for VGA2SCART patch set
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[rewrapped to fit <= 80 columns]
I demand that Timothy D. Lenz may or may not have written...
First, I don't know why, but everyone of your post comes through as a text attachment which has to be saved out to be read. Others on the list come through normal.
They look fine here. However, I notice that they're GPG-signed and have a structure as follows:
multipart/mixed multipart/signed text/plain application/pgp-signature text/plain
This last text/plain section is added by the list software; it's presumably also that which adds the containing multipart/mixed and moves the Content-Type header for the multipart/signed section out of the message headers into a MIME headers section in the message body.
This is signed by way of experiment; as sent, it has multipart/signed in the message headers. If you see the same with this message, you have buggy mail software (but seeing that it's MICROS~1 Lookout Express, that's not really surprising).
[snip]
Same thing, just attachments. And I turn off a lot of the fancy crap in mail programs to reduce the chance of them running some virus attached to the mail. Mail should be text and any code should be limited to files that are in no way run by the mail program. Some things are just ment to be seen or read, not run. If ms woke up to that fact, there be a lot less ways to infect computers.
----- Original Message ----- From: "Darren Salt" linux@youmustbejoking.demon.co.uk To: vdr@linuxtv.org Sent: Wednesday, March 04, 2009 4:43 PM Subject: Re: [vdr] [OT] development infrastructur for VGA2SCART patch set
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
En/na Timothy D. Lenz ha escrit:
Mail should be text and any code should be limited to files that are in no way run by the mail program.
Fact is, it *is* text. The problem is that outlook doesn't qualify as an email reader. Postel's law http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_Law says "be conservative in what you send, be liberal in what you receive", the exact opposite of what outlook does: it sends crap (e.g. winmail.dat) but it cannot render a correctly formed *text* mail message. Do the world a favour and use a real email program, or stop complaining about well formed messages.
Bye
Dear everyone,
Am Donnerstag, den 05.03.2009, 20:51 +0100 schrieb Luca Olivetti:
En/na Timothy D. Lenz ha escrit:
Mail should be text and any code should be limited to files that are
in no way run by the mail program.
[…]
Do the world a favour and use a real email program, or stop complaining about well formed messages.
Although I agree, I want to thank Timothy for at least answering me.
Thanks Timothy,
Paul
Paul Menzel wrote:
@Tobi: Could the patches be hosted on projects.vdr-developers.org?
In general I would have no objections against this. What kind of patches is this all about? I haven't followed this VGA2SCART thing, but a quick lookup showed, that this involves patching XOrg stuff and xineliboutput. If this is the case, then a single Git repository might not be appropriate.
Tobias
Am Sonntag, den 01.03.2009, 00:29 +0100 schrieb Tobi:
Paul Menzel wrote:
@Tobi: Could the patches be hosted on projects.vdr-developers.org?
In general I would have no objections against this. What kind of patches is this all about? I haven't followed this VGA2SCART thing, but a quick lookup showed, that this involves patching XOrg stuff and xineliboutput.
That is correct. It requires several programs to be patched.
If this is the case, then a single Git repository might not be appropriate.
Right. Creating a directory for each individual program might not be the best solution.
Let us wait, what Thomas will answer.
Thanks for your reply,
Paul
On Sun, Mar 01, 2009 at 01:13:32AM +0100, Paul Menzel wrote:
In general I would have no objections against this. What kind of patches is this all about? I haven't followed this VGA2SCART thing, but a quick lookup showed, that this involves patching XOrg stuff and xineliboutput.
That is correct. It requires several programs to be patched.
If this is the case, then a single Git repository might not be appropriate.
we must distinguish 4 cases. VGA2SCART on:
1. ATI Radeon without FRC 2. Intel i9xx without FRC 3. ATI Radeon with FRC 4. Intel i9xx with FRC
software patches required:
1. - xserver-xorg-video-radeon (newer versions may not need it) 2. - xserver-xorg-video-intel 3. - xserver-xorg-video-radeon - xineliboutput (newer versions already adopted the patch) - xine-lib - radeon-drm kernel module 4. - xserver-xorg-video-intel - xineliboutput (newer versions already adopted the patch) - xine-lib
FRC stands for frame rate control. That means VGA video timing is synchronized with DVB stream => no software deinterlacing is needed any more. Fields are forwarded directly from softdecoder to VGA port.
The simple version without FRC allows conventional operation (with software deinterlacing). It provides the minimum requirements needed for SCART over VGA.
I don't know either how to maintain the patch set. So at least I took a few snapshots from my development and collected them at 'http://lowbyte.de/vga-sync-fields/'
- Thomas
In general I would have no objections against this. What kind of patches is this all about? I haven't followed this VGA2SCART thing, but a quick lookup showed, that this involves patching XOrg stuff and xineliboutput.
That is correct. It requires several programs to be patched.
If this is the case, then a single Git repository might not be appropriate.
we must distinguish 4 cases. VGA2SCART on:
and what about of nvidia vdpau cards ?
- ATI Radeon without FRC
- Intel i9xx without FRC
- ATI Radeon with FRC
- Intel i9xx with FRC
Goga
Goga777 schrieb:
In general I would have no objections against this. What kind of patches is this all about? I haven't followed this VGA2SCART thing, but a quick lookup showed, that this involves patching XOrg stuff and xineliboutput.
That is correct. It requires several programs to be patched.
If this is the case, then a single Git repository might not be appropriate.
we must distinguish 4 cases. VGA2SCART on:
and what about of nvidia vdpau cards ?
It's a binary driver, so I don't think you can patch anything there.
- jan
On Sun, Mar 01, 2009 at 04:09:23PM +0100, Jan Willies wrote:
It's a binary driver, so I don't think you can patch anything there.
exactly. But many nVidia chips are VGA2SCART capable (without FRC of course) directly with the binary driver. Just a proper xorg.conf is needed.
- Thomas
It's a binary driver, so I don't think you can patch anything there.
exactly. But many nVidia chips are VGA2SCART capable (without FRC of course) directly with the binary driver. Just a proper xorg.conf is needed.
please - could you point out please on proper xorg.conf
does that xorg.conf corrected ? http://mymediasystem.net/wp/2009/02/xorg.conf1
Goga
On Mon, Mar 02, 2009 at 12:33:48AM +0300, Goga777 wrote:
please - could you point out please on proper xorg.conf
you'll find one attached. I use it on my Asus Pundit P1_AH2. System is quite old (but stable):
debian etch based xserver-xorg 7.1.0-19 NVIDIA-Linux-x86-100.14.19
more recent systems might need some adaptions
does that xorg.conf corrected ? http://mymediasystem.net/wp/2009/02/xorg.conf1
it appears it's not a PAL modeline. Instead 1920x1080 is used.
- Thomas
On Sun, Mar 01, 2009 at 11:06:44PM +0100, Thomas Hilber wrote:
On Mon, Mar 02, 2009 at 12:33:48AM +0300, Goga777 wrote:
please - could you point out please on proper xorg.conf
you'll find one attached. I use it on my Asus Pundit P1_AH2. System is quite old (but stable):
debian etch based xserver-xorg 7.1.0-19 NVIDIA-Linux-x86-100.14.19
more recent systems might need some adaptions
does that xorg.conf corrected ? http://mymediasystem.net/wp/2009/02/xorg.conf1
it appears it's not a PAL modeline. Instead 1920x1080 is used.
Hmm.. so you get 50 Hz interlaced output with this xorg.conf.
Are you able to sync to each field separately?
-- Pasi
- Thomas
Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" 0 0 InputDevice "Generic Keyboard" InputDevice "Configured Mouse" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection
Section "Files" FontPath "/usr/share/fonts/X11/misc" EndSection
Section "Module" Load "i2c" Load "bitmap" Load "ddc" Load "extmod" Load "freetype" # Load "glx" Load "int10" Load "vbe" EndSection
Section "ServerFlags" Option "AllowMouseOpenFail" "on" EndSection
Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "CoreKeyboard" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection
Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device" "/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" EndSection
Section "Monitor" Identifier "Generic Monitor" Option "DPMS"
HorizSync 15-16 Modeline "720x576i" 13.875 720 744 808 888 576 580 585 625 -HSync -Vsync interlaceEndSection
Section "Device"
Option "UseEDID" "FALSE" Option "UseEvents" "True" Option "NoLogo" "True" Identifier "Generic Video Card" Driver "nvidia"EndSection
Section "Screen" Identifier "Default Screen" Device "Generic Video Card" Monitor "Generic Monitor" DefaultDepth 24
SubSection "Display"Depth 24
Modes "720x576i"
EndSubSectionEndSection
On Mon, Mar 02, 2009 at 10:03:12AM +0200, Pasi Kärkkäinen wrote:
Hmm.. so you get 50 Hz interlaced output with this xorg.conf.
Are you able to sync to each field separately?
of course not on nVidia graphics. They haven't offered their specs for us to implement that.
But nevertheless this modeline gives smooth PAL playback because the display (a SCART device) inherently plays 50Hz.
The major disadvantage of missing capability to have sync to field is: you must deinterlace by software. Though you use an interlaced VGA output. And software deinterlacers as we all know cause bad picture quality.
Sync to separate fields currently only works with ATI Radeon and Intel i9xx chipsets. That's what FrameRateControl (FRC) is based upon in the patches mentioned above. This way you can cease from deinterlacing in software giving you an artifact free picture.
- Thomas
On 21 Jan 2009, at 15:02, Thomas Hilber wrote:
patch version II: http://www.vdr-portal.de/board/thread.php?postid=769703#post769703
I tried patching the i810 driver that comes with fedora 9, which i use, but I'm getting
patching file ./src/i830_driver.c Hunk #1 FAILED at 319. Hunk #2 FAILED at 352. Hunk #3 succeeded at 1663 (offset -56 lines). 2 out of 4 hunks FAILED -- saving rejects to file ./src/ i830_driver.c.rej patching file ./src/i830_video.c
Which driver source is suitable for patch II?
On 22 Jan 2009, at 21:12, Torgeir Veimo wrote:
On 21 Jan 2009, at 15:02, Thomas Hilber wrote:
patch version II: http://www.vdr-portal.de/board/thread.php?postid=769703#post769703
I tried patching the i810 driver that comes with fedora 9, which i use, but I'm getting
patching file ./src/i830_driver.c Hunk #1 FAILED at 319. Hunk #2 FAILED at 352. Hunk #3 succeeded at 1663 (offset -56 lines). 2 out of 4 hunks FAILED -- saving rejects to file ./src/ i830_driver.c.rej patching file ./src/i830_video.c
Which driver source is suitable for patch II?
It looks like the patch references a version of the driver that supports OPTION_RENDERACCEL, but v 2.3.2 doesn't support that. Which version of the driver is the patch for?
On Thu, Jan 22, 2009 at 10:07:57PM +1000, Torgeir Veimo wrote:
It looks like the patch references a version of the driver that supports OPTION_RENDERACCEL, but v 2.3.2 doesn't support that. Which version of the driver is the patch for?
as described in
http://www.vdr-portal.de/board/thread.php?postid=769703#post769703
the patch originally is against debian 'xserver-xorg-video-intel_2.3.2-2+lenny5_i386.deb'. There occur only some trivial rejects with your version of xserver-xorg-video-intel. The patch does not interfere much with the original code. I hope you can resolve them manually.
On Thu, Jan 22, 2009 at 09:12:12PM +1000, Torgeir Veimo wrote:
I tried patching the i810 driver that comes with fedora 9, which i use, but I'm getting
But please keep in mind it only works for i9xx chipsets (not the i810/i815)
- Thomas
-
Darren Salt -
Goga777 -
Jan Willies -
Luca Olivetti -
Morfsta -
Nicolas Huillard -
Pasi Kärkkäinen -
Paul Menzel -
Scott Waye -
Thomas Hilber -
Timothy D. Lenz -
Tobi -
Tony Houghton -
Torgeir Veimo -
Ville Aakko