[patch] RGB/PAL ueber VGA mit variabler Framerate

Hallo Sparkie,

der zweite Schritt ist ja RGB/PAL interlaced auszugeben. Das hast du geschafft.
Da dein Patch momentan für meine Distri nicht zur Verfügung steht, versuche ich das Bild progressiv über Xineliboutput in der Nativen Auflösung auszugeben.

Das war sicher auch dein erster Schritt, oder?

Hast du von 'damals' noch eine funktionierende xorg.conf/modeline?
Ich schaffe es einfach nicht, 720/768x576 *mit 50Hz* auszugeben. (siehe X Auflösung auf 720x576_50)

Gruß&Danke,
Hendrik

Hi sparkie,

ich habe mich gleich an die Arbeit gemacht und versucht zu patchen. Unter archlinux ist Kernel 2.6.28
aktuell. Dabei änderte sich die Dateistruktur etwas (Verschiebung in das Verzeichnis <gpu/[radeon]> und
Includedateien sind nun auch in </linux/include>.
Das lässt sich aber eigentlich noch problemlos lösen, bin aber trotzdem auf die libdrm aus dem git-repo
ausgewichen.
Ich komme aber beim Patchen der Datei radeon_drv.c nicht weiter, wo es um vblanks geht:

+void radeon_handle_vblank(struct drm_device *dev, int crtc)
+{
+    drm_radeon_private_t *dev_priv =
+            (drm_radeon_private_t *)dev->dev_private;
+
+    if (RADEON_READ(RADEON_CRTC_STATUS) & 0x08) {
+	if (!(atomic_read(&dev->vbl_received) & 1)) {
+	    atomic_inc(&dev->vbl_received);
+	    printk(KERN_DEBUG "[drm] field polarity corrected, odd -> %d\n", atomic_read(&dev->vbl_received));
+	}
+	do_gettimeofday(&dev_priv->tv_vbl);
+    } else {
+	if (atomic_read(&dev->vbl_received) & 1) {
+	    printk(KERN_DEBUG "[drm] field polarity error A\n");
+	}
+    }
+
+    /*
+     * if requested we tamper with length of few
+     * horizontal lines here.
+     *
+     * don't try this at home:-)
+     */
+    if (dev_priv->trim) {
+	int val = RADEON_READ(RADEON_CRTC_H_TOTAL_DISP);
+	int tmp0 = val + (char)(dev_priv->trim & 0xff);
+	int tmp2 = (dev_priv->trim >> 16 & 0xff) + VSF_HLINE_BIAS;
+	int tmp1 = tmp2 + (dev_priv->trim >> 8 & 0xff);
+
+	while (RADEON_READ(RADEON_CRTC_VLINE_CRNT_VLINE) >> 16 < tmp2);
+	RADEON_WRITE(RADEON_CRTC_H_TOTAL_DISP, tmp0);
+	while (RADEON_READ(RADEON_CRTC_VLINE_CRNT_VLINE) >> 16 < tmp1);
+	RADEON_WRITE(RADEON_CRTC_H_TOTAL_DISP, val);
+    }
+}
 
 irqreturn_t radeon_driver_irq_handler(DRM_IRQ_ARGS)
 {
@@ -102,6 +137,7 @@
 			    (vblank_crtc & DRM_RADEON_VBLANK_CRTC2)))
 			atomic_inc(&dev->vbl_received);
 
+		radeon_handle_vblank(dev, VSF_CRTC);
 		DRM_WAKEUP(&dev->vbl_queue);
 		drm_vbl_send_signals(dev);
 	}

Der Fehler geht dabei von

&dev->vbl_received

aus, was scheinbar in neueren Versionen abgeändert wurde.
Auch weiß ich nicht, wo die folgende Zeile hingehört, weil da auch noch andere vblank-Signale ausgelöst werden:

radeon_handle_vblank(dev, VSF_CRTC);

Testweise habe ich diese Codestellen einmal weggelassen und durchkompiliert. Es lässt sich soweit alles laden,
aber ob es trotzdem funktioniert, kann ich aber gar nicht sagen. Am Wochenende werde ich das noch einmal genauer untersuchen.

So long.

Hi sparkie,

Zitat

gab es dafuer einen Grund? Im GIT ist naemlich einiger Treiber-Code, den der Xserver noch nutzt, nur noch als 'deprecated' enthalten. Der Crash haengt ebenfalls damit zusammen.
- sparkie

Danke für den Tipp. Ich hatte auch tatsächlich gleich einen Absturz beim Beenden des Xservers, der wohl daher kommt.
Ich verwendete libdrm-git eigentlich nur aus Bequemlichkeit, weil ich dafür ein PKGBUILD angepasst hatte und wusste, dass es schon einmal durchkompilierte.
Ich mache mich gleich daran, die Sourcen aus dem aktuellen Kernel anzupassen und zu kompilieren.

Bei der Sache mit &dev->vbl_received komme ich aber glaube ich nicht weiter. Ich werde mir das aber trotzdem mal anschauen. Vielleicht finde ich etwas dazu.

EDIT:
Das neue struct dev_drm sieht in KERNEL-2.6.28-ARCH so aus (drmP.h):

/**
 * DRM device structure. This structure represent a complete card that
 * may contain multiple heads.
 */
struct drm_device {
	char *unique;			/**< Unique identifier: e.g., busid */
	int unique_len;			/**< Length of unique field */
	char *devname;			/**< For /proc/interrupts */
	int if_version;			/**< Highest interface version set */


	int blocked;			/**< Blocked due to VC switch? */


	/** \name Locks */
	/*@{ */
	spinlock_t count_lock;		/**< For inuse, drm_device::open_count, drm_device::buf_use */
	struct mutex struct_mutex;	/**< For others */
	/*@} */


	/** \name Usage Counters */
	/*@{ */
	int open_count;			/**< Outstanding files open */
	atomic_t ioctl_count;		/**< Outstanding IOCTLs pending */
	atomic_t vma_count;		/**< Outstanding vma areas open */
	int buf_use;			/**< Buffers in use -- cannot alloc */
	atomic_t buf_alloc;		/**< Buffer allocation in progress */
	/*@} */


	/** \name Performance counters */
	/*@{ */
	unsigned long counters;
	enum drm_stat_type types[15];
	atomic_t counts[15];
	/*@} */


	/** \name Authentication */
	/*@{ */
	struct list_head filelist;
	struct drm_open_hash magiclist;	/**< magic hash table */
	struct list_head magicfree;
	/*@} */


	/** \name Memory management */
	/*@{ */
	struct list_head maplist;	/**< Linked list of regions */
	int map_count;			/**< Number of mappable regions */
	struct drm_open_hash map_hash;	/**< User token hash table for maps */


	/** \name Context handle management */
	/*@{ */
	struct list_head ctxlist;	/**< Linked list of context handles */
	int ctx_count;			/**< Number of context handles */
	struct mutex ctxlist_mutex;	/**< For ctxlist */


	struct idr ctx_idr;


	struct list_head vmalist;	/**< List of vmas (for debugging) */
	struct drm_lock_data lock;	/**< Information on hardware lock */
	/*@} */


	/** \name DMA queues (contexts) */
	/*@{ */
	int queue_count;		/**< Number of active DMA queues */
	int queue_reserved;		  /**< Number of reserved DMA queues */
	int queue_slots;		/**< Actual length of queuelist */
	struct drm_queue **queuelist;	/**< Vector of pointers to DMA queues */
	struct drm_device_dma *dma;		/**< Optional pointer for DMA support */
	/*@} */


	/** \name Context support */
	/*@{ */
	int irq_enabled;		/**< True if irq handler is enabled */
	__volatile__ long context_flag;	/**< Context swapping flag */
	__volatile__ long interrupt_flag; /**< Interruption handler flag */
	__volatile__ long dma_flag;	/**< DMA dispatch flag */
	struct timer_list timer;	/**< Timer for delaying ctx switch */
	wait_queue_head_t context_wait;	/**< Processes waiting on ctx switch */
	int last_checked;		/**< Last context checked for DMA */
	int last_context;		/**< Last current context */
	unsigned long last_switch;	/**< jiffies at last context switch */
	/*@} */


	struct work_struct work;
	/** \name VBLANK IRQ support */
	/*@{ */


	/*
	 * At load time, disabling the vblank interrupt won't be allowed since
	 * old clients may not call the modeset ioctl and therefore misbehave.
	 * Once the modeset ioctl *has* been called though, we can safely
	 * disable them when unused.
	 */
	int vblank_disable_allowed;


	wait_queue_head_t *vbl_queue;   /**< VBLANK wait queue */
	atomic_t *_vblank_count;        /**< number of VBLANK interrupts (driver must alloc the right number of counters) */
	spinlock_t vbl_lock;
	struct list_head *vbl_sigs;	/**< signal list to send on VBLANK */
	atomic_t vbl_signal_pending;    /* number of signals pending on all crtcs*/
	atomic_t *vblank_refcount;      /* number of users of vblank interruptsper crtc */
	u32 *last_vblank;               /* protected by dev->vbl_lock, used */
					/* for wraparound handling */
	int *vblank_enabled;            /* so we don't call enable more than
					   once per disable */
	int *vblank_inmodeset;          /* Display driver is setting mode */
	struct timer_list vblank_disable_timer;


	u32 max_vblank_count;           /**< size of vblank counter register */


	/*@} */
	cycles_t ctx_start;
	cycles_t lck_start;


	struct fasync_struct *buf_async;/**< Processes waiting for SIGIO */
	wait_queue_head_t buf_readers;	/**< Processes waiting to read */
	wait_queue_head_t buf_writers;	/**< Processes waiting to ctx switch */


	struct drm_agp_head *agp;	/**< AGP data */


	struct pci_dev *pdev;		/**< PCI device structure */
	int pci_vendor;			/**< PCI vendor id */
	int pci_device;			/**< PCI device id */
#ifdef __alpha__
	struct pci_controller *hose;
#endif
	struct drm_sg_mem *sg;	/**< Scatter gather memory */
	int num_crtcs;                  /**< Number of CRTCs on this device */
	void *dev_private;		/**< device private data */
	struct drm_sigdata sigdata;	   /**< For block_all_signals */
	sigset_t sigmask;


	struct drm_driver *driver;
	drm_local_map_t *agp_buffer_map;
	unsigned int agp_buffer_token;
	struct drm_minor *primary;		/**< render type primary screen head */


	/** \name Drawable information */
	/*@{ */
	spinlock_t drw_lock;
	struct idr drw_idr;
	/*@} */


	/** \name GEM information */
	/*@{ */
	spinlock_t object_name_lock;
	struct idr object_name_idr;
	atomic_t object_count;
	atomic_t object_memory;
	atomic_t pin_count;
	atomic_t pin_memory;
	atomic_t gtt_count;
	atomic_t gtt_memory;
	uint32_t gtt_total;
	uint32_t invalidate_domains;    /* domains pending invalidation */
	uint32_t flush_domains;         /* domains pending flush */
	/*@} */


};

Ich habe nun vbl_received durch _vblank_count ersetzt.
Auch habe ich auf der neuen Wikiseite gelesen, dass im upstream-Paket xf86-video-ati etwas getan wird. Aber mehr konnte ich da nicht herauslesen. Weißt du da mehr? Möglicherweise ist dieser Passus mit vblank gar nicht nötig?

So long.

Hi,

ich versuche gerade die Patches auf meinem Gen2VDR einzuarbeiten. Im Prinzip klappt alles, nur das Radeon-Modul bekomme ich nicht übersetzt. Ich benutze die Version 6.12.1-r1 von xf86-video-ati. Dein xv-radeon-patch mußte ich ein wenig anpassen, danach ist er sauber durchgelaufen. Nur beim kompilieren spuckt er jetzt diese Meldung aus:

radeon_video.c: In function 'vga_sync_fields':
radeon_video.c:4105: error: 'struct <anonymous>' has no member named 'drmFD'
radeon_video.c:4112: error: 'struct <anonymous>' has no member named 'drmFD'
radeon_video.c:4195: warning: suggest parentheses around arithmetic in operand of |
radeon_video.c:4196: error: 'struct <anonymous>' has no member named 'drmFD'
make[2]: *** [radeon_video.lo] Error 1 make[2]: Leaving directory `/mnt/data/tmp/portage/x11-drivers/xf86-video-ati-6.12.1-r1/work/xf86-video-ati-6.12.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/mnt/data/tmp/portage/x11-drivers/xf86-video-ati-6.12.1-r1/work/xf86-video-ati-6.12.1'
make: *** [all] Error 2

Hat jemand eine Idee was ich verkehrt mache oder vergessen habe?

MfG
Daniel

Hi Sparkie,

Zitat

Auf Lenny kommt jedoch Version 6.9.0 zum EInsatz.

Die gibt es bei Gentoo leider nicht mehr. Werd mal schauen ob ich da noch ein Ebuild finde.

Zitat

schau evtl. mal ob der Filedescriptor in der Struktur RADEONInfoPtr jetzt nur anders heisst als 'drmFD'.

Würd ich ja tun, nur weiß ich nicht wo. Ich kann zwar Patches usw. anpassen, aber wenns um programmiertechnischen Kram selber geht, komme ich nicht mehr weiter.

Zitat

Ist eben speziell fuer Debian Lenny zugeschnitten. Es waere ein ziemlicher Aufwand, da alle aktuellen sonstigen Distris ebenfalls zu beruecksichtigen

Jo, falls es nicht klappt, dann halt nicht, aber so schnell wollte ich eigentlich nicht aufgeben

MfG
Daniel

Hi,

sorry für den Doppelpost.

So, ich habe es geschaftt den xv-radeon.patch auf die 6.9.0er Version anzuwenden. Dazu mußte ich auch noch den Lenny4-Patch (s.u.) anwenden (vor dem xv-radeon), aber dann hat er sauber durchkompiliert. Laut Xorg.0.log schein vga-sync.fields auch zu laufen, aber sobald ich ein Video starte oder vdr-sxfe, stürtzt X ab. Im Anhang die Xorg.0.log.
Scheinbar hat das immernoch mit dem drmFD zu tun, aber ich weiß einfach nicht, wo ich da anfangen soll zu suchen.

Hier noch kurz was genau installiert ist:
Kernel: linux-2.6.26-gentoo-r4 incl. dem fb-drm-radeon-intel.patch (gibt es spezielle Sources für Debian lenny? Wo? Patches?)
Xserver: xorg-server-1.5.3
libdrm 2.4.5 mit frc patch von Durchflieger (könnte hier das Problem liegen?)
xf86-video-ati-6.9.0 mit xserver-xorg-video-ati_6.9.0-1+lenny4.diff und xv-radeon.patch

Ich glaube ich werde morgen nochmal alles neu machen und schauen was dann passiert.

MfG
Daniel

Hi!
Die aktuellen patches v0.2.0 setzen bei mir die Framebuffer PAL-Auflösung beim booten nicht, obwohl ich mich an die Anleitung gehalten habe, und X zB auch in PAL-Auflösung läuft.
System ist Debian/lenny mit dem aktuellen gepatchtem Kernel 2.6.26-2.
Graka (Radeon 9250):
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01)
01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01)

Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.26 root=UUID=xxxxxxxxxx ro video=radeonfb:720x576-32@50i

dmesg liefert dann:
[ 0.456452] radeonfb: Found Intel x86 BIOS ROM Image
[ 0.456501] radeonfb: Retrieved PLL infos from BIOS
[ 0.456549] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, System=166.00 MHz
[ 0.456608] radeonfb: PLL min 20000 max 40000
[ 0.457656] radeonfb: Monitor 1 type CRT found
[ 0.457701] radeonfb: Monitor 2 type no found
[ 0.498777] Console: switching to colour frame buffer device 100x37
[ 0.527213] radeonfb (0000:01:00.0): ATI Radeon 5960 "Y`"
[ 0.527894] isapnp: Scanning for PnP cards...
[ 0.764027] Switched to high resolution mode on CPU 0
[ 0.881929] isapnp: No Plug & Play device found
[ 0.886157] Linux agpgart interface v0.103
[ 0.886413] intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/965G/965GM chipsets
[ 0.886797] intelfb: Version 0.9.5
[ 0.886991] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
[ 0.887426] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
...
Einkompiliert ist hier radeonfb, intelfb und auch lirc (also nicht wundern)

scheinbar ist da PLL min immer noch bei 20000, wo man doch eine min von 12000 bräuchte. Wahrscheinlich wird deshalb eine andere Auflösung statt PAL gesetzt, denn später lande ich bei:

satvdr:~# fbset -i -v
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "800x600-56"
# D: 36.001 MHz, H: 35.157 kHz, V: 56.252 Hz
geometry 800 600 800 600 32
timings 27777 128 24 22 1 72 2
rgba 8/16,8/8,8/0,0/0
endmode

Getting further frame buffer information
Frame buffer device information:
Name : ATI Radeon 5960
Address : 0xd8000000
Size : 134217728
Type : PACKED PIXELS
Visual : DIRECTCOLOR
XPanStep : 8
YPanStep : 1
YWrapStep : 0
LineLength : 3200
MMIO Address: 0xe8020000
MMIO Size : 16384
Accelerator : ATI Radeon family

Hmm, irgendwelche Lösungsvorschläge?

NACHTRAG:
Scheinbar patcht der radeon-PLL-patch irgendwas in der falschen Zeile im Kernel, radeon_base.c
Da passen nämlich die Kernel -Kommentare gar nicht mehr mit den Log-Ausgaben des patches zusammen!
Da wird die ppll_min nur auf 12000 gesenkt, wenn man einen x86 hat? Hääh, ich habe aber nen x86 laufen (AMD Athlon(tm) XP 1800+) und trotzdem wird laut kernel-log erst das nächste IF ausgeführt!?!

Ich probier' mal, den patch anzupassen und neu zu kompilieren...

Es läuft jetzt. Allerdings mit einem gepatchtem e-tobi 2.6.28er Kernel.
Frag mich nicht warum das auf einmal geht - ich hab praktisch einen unveränderte Änderung in radeon_base.c

Folgendes kommt jetzt mit der 9250er:
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.28-20090916 root=UUID=xxxxxxx ro video=radeonfb:800x520-32@50i
[ 0.510352] radeonfb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 0.511551] radeonfb: Found Intel x86 BIOS ROM Image
[ 0.511601] radeonfb: Retrieved PLL infos from BIOS
[ 0.511647] radeonfb: disregarding BIOS ppll_min of 20000
[ 0.511694] radeonfb: using ppll_min of 12000 instead
[ 0.511741] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, System=166.00 MHz
[ 0.511800] radeonfb: PLL min 12000 max 40000
[ 0.512853] radeonfb: Monitor 1 type CRT found
[ 0.512899] radeonfb: Monitor 2 type no found
[ 0.633302] radeonfb (0000:01:00.0): ATI Radeon 5960 "Y`"

Verbesserungsvorschläge:
Das hier gilt alles für meine Radeon 9250 auf Standard-PAL-TV
pal_modeline:
Die Ausgabe stimmt nicht, bzw stimmt die nicht mit dem empfohlenen Patches zusammen.
-hsync und -vsync sollten false sein (oder weglassen) für den Framebuffer
- accel true könne man noch setzen (falls das was bringt; funktioniert jedenfalls)
Modeline für X11 ist auch nicht die, die in der xorg.conf empfohlen wird
Passendes wäre also:
fbset -g 720 576 720 576 32 -t 74074 64 16 39 5 64 5 -laced true -accel
oder
fbset -g 800 520 800 520 32 -t 58823 144 64 72 28 80 5 -laced true -accel true

INSTALL:
Beim Kernelbauen baut das Buildsystem alle 10(?) Kernel-Varianten, was ewig dauert und nicht nötig ist.
Also lieber so bauen:
apt-get build-dep linux-image-2.6.26-2-686
apt-get source linux-2.6
cd linux-2.6-2.6.26
cp /boot/config-2.6.26-2-686 .config
make oldconfig
patch -p1 </pfad/zum/patch
make-kpkg kernel_image --initrd
Allerdings sind da modifizierte patches nötig, die vom linux-2.6-2.6.26-Verzeichnis mit -p1 durchlaufen.
Man spart sich damit auch den meiner Meinung nach umständlichen Schritt zuerst zu bauen, dann nach debian/build/build_i386_none_686 gehen, patchen, nochmal bauen,...
Bei mir hätte man ein .deb in einem Rutsch.
Das gilt übrigens für alle Debian-Pakete. Es ist überhaupt nicht notwendig, zuerst ein dpkg-buildpackage auszuführen oder manuell Module zumzukopieren, wie etwa:
cp ./src/.libs/radeon_drv.so /usr/lib/xorg/modules/drivers
Es genügt, gleich zu patchen, und dann dpkg-buildpackage auszuführen, was ein gepatchtes deb erzeugt.
(oder hab ich da vielleicht einen tieferen Sinn übersehen)

Frage noch am Schluss:
xine-lib und vdr-plugin-xineliboutput sind in Debian/testing zu finden, mit zT neuerer Version, als bei deiner Anleitung mit CVS oder Sourceforge
Ich hab die gepatcht und durchkompiliert. Allerdings semmelt VDR dann bei aktiviertem sync-fields ab (Schaltet man das in xorg.conf aus, gibts zumindest keine Abstürze von X11)
Hast du ne Ahnung was da an den xine-libs von Debian verändert/verschlimmbessert wurde?

Grüße.....

Nachtrag:
drift_control und dumpio gehen nur, wenn ich für meine Radeon 9250 den device-id 0x5960 hinzufüge.

Hallo zusammen,

Zitat

Original von Hitman47
Hi sparkie,

ich habe mich gleich an die Arbeit gemacht und versucht zu patchen. Unter archlinux ist Kernel 2.6.28
aktuell. Dabei änderte sich die Dateistruktur etwas (Verschiebung in das Verzeichnis <gpu/[radeon]> und
Includedateien sind nun auch in </linux/include>.

ich habe in den letzten Tagen Ubuntu Karmic aufgesetzt inkl. VDR 1.7.10. Da ich noch eine Radeon 7000 aufgetrieben habe und auch die Bauteile für ein VGA2SCART-Kabel hier hätte, wollte ich die Patches ausprobieren. Ich bin wie in INSTALL (http://lowbyte.de/vga-sync-fields/vga-sync-fields/INSTALL) beschrieben vorgegangen, stehe beim Patchen mit "fb-drm-radeon-intel.patch" jetzt aber auch vor dem Problem, dass die Dateien nicht mehr dort liegen, wo das Patch-File sie erwartet.

radeon_drm.h liegt liegt include/drm/ und radeon_drv.h unter drivers/gpu/drm/radeon/. Alle Files liegen aber außerhalb des "build"-Verzeichnisses.

Ich bin hier momentan etwas ratlos wie es weitergeht. Ist hier vielleicht sonst noch jemand mit einem aktuellen Ubuntu unterwegs und kann mir ein paar Tips geben?

Vielen Dank im Voraus
Andreas