hi,
r4 is im kasten... 
bugreport hab ich gemacht (enhancement)
die entwickler von xine-lib müsste man mal fragen...
der patch ist ein derivat direkt von dem tarball des vdr-xine-0.1.1.tar.gz (??)
halt eine zusammenfassung, eingezippe'd (als *.diff ca. 50k - zu gross für meinen geschmack, deswegen *.diff.bz2)
so, und jetz hab ich tatsächlich besseres zu tun *grins*
viel spass heute noch
gruss
florian
hi,
sieht gut aus... - sehr schön
hmm, habe gerade eine xine-lib -r1 in den cvs gestellt...
diese unterstützt jetzt auch USE="vdr"...
damit wird die nutzung des vdrplugin-xine ermöglicht... ebuild für plugin selbst folgt...
einfach
ACCEPT_KEYWORDS="~x86" USE="vdr" emerge xine-lib
oder
in /etc/make.conf eintragen...
more to come...
schöne weihnachten
gruss
florian
moin,
aaalso:
neue version; die icons gehen jetzt nach /usr/share/vdr/icons
bauen + installieren geht; ob der iosd-patch die icons allerdings aus dem richtigen verzeichniss holt ???
hab auf dieser maschine nicht die möglichkeit, das zu testen.
der pfad ist jedenfalls angepasst, also wirds schon gehen, denke ich...
soderle, versuchts mal... + sagt mir bescheid.
mit der ebuild logik blick ich allerdings langsam nimmer durch... *grins* und das wird noch schlimmer...
denke, werd mal so auf if / elif / elif /elif und auf auslagern gehen, wenn ihr nix dagegen habt...
was meint ihr?
ach ja, was ganz anderes, liegt mir aber persönlich am herzen:
bzgl. mplayer-plugin / xine-plugin:
wie ihr ja wisst, muss man die zugrundeliegende software patchen um sie verwenden zu können; die derzeitigen ebuilds fangen das nicht ab.
ich würde gerne in den mplayer den slave patch einbauen ( u.u. per USE="+vdr")
bei xine-lib das gleiche...
nun, diese USE-flag existiert nicht... vorschläge eurerseits diesbezüglich?
gruss
florian
hoi henning,
klar, das ginge schon...
aber wenn dann nur fakultativ, oder? so über VDR_OPTS, mein ich...
bin grad an den icons dran...
werde dann mal ( u.u.erst morgen) mal wieder eine version posten...
ach ja mad: dein beauty patch für die plugin liste ist echt schick...
was so'n ebuild alles kann - echt nett
ach ja:
dieser thread gefällt mir gut - kommt viel dabei raus.
dank an euch alle
gruss
rootshell
p.s.
wegen den patchfehlern:
also mit nem offset könnte ich zur not leben - was mir sorgen bereitet
sind die rejects - schliesslich wandert hier definitiv code auf den müll...
solltest dir mal die .rej ansehen, was das genau ist.
ansonsten würde ich einen downgrade empfehlen oder eine manuelle neuanpassung der patches ;-(((
nur nichtbeachten ist, denke ich, falsch...
hi,
ja, der muss natürlich auch raus - hatte ich übersehen; aber klar
gruss
rootshell
hi henning,
den fehler hab ich behoben... waren die [ ] -> zuviel...
ach ja: das '||' ist ein logisches oder; dementspechend '&&' logisches und...
gruss
rootshell
p.s.
wegen dem logofile - dank dir dafür - werde das noch einbauen...
hi,
also hier kommt die 2te version...
scheint alles zu gehen...
ausserdem gibt das ebuild am ende ein liste der installierten plugins aus (so per ebuild installiert)
desweiteren muss das gentoolkit installiert sein (eh eine gute idee ;)) (wird aber i.a nicht abgefangen...)
die installation der icons nur, wenn akool oder iosd in VDR_OPTS;
allerdings dann nach /etc/vdr/icons...
ändern kann man das schnell; wie gelangt eigentlich der iosd-patch an die icons??? hart codiert???
hab da noch ned reingeschaut...
muss man dann auch hier irgendwo was abfangen? (frage mad) weisst du das?
dann kann man die plugins hinlegen, wo immer man will...
so, bitte testen...
gruss
rootshell
hi,
ja, ich sehe, da si noch e bissl der wurm drinne...
ich konnte das teil ja nichtmal selbst testen, mangels linux;
ein paar fehler hab ich jetzt schon gefunden, bei der duchsicht, nachdem ich deine
meldungen gelesen habe...
werde das dann noch beheben...
lieber morgen, wenn ich wieder gentoo hab, hehe...
und bzgl. der installationsorte - klar; das war nie meine absicht, dahin zu installieren;
fehler noch...
gruss
rootshell
hi,
zuallererst:
hier kommt der experimentelle ebuild...
da ich gerade an einer windows maschine sitze und keinen zugriff auf ein
gentoo system habe, kann es sein, dass es nicht funktioniert... 
sollte aber schon, denke ich...
morgen hab ich wieder gentoo.
die auslagerung von sed in ein separates script dann in der "final"
Henning:
dass das mit meinen C[XX]FLAGS vorschlägen nicht auf meinem "mist" gewachsen ist,
hier ein kleines excerpt aus der gentoo-dev ML:
# Recently there has been a lot of stability problem in Gentoo-land. Many
# things can be the cause to this, but I believe that it is due to gcc3
# still having issues with optimizations, or with it not filtering bad
# combinations (protecting the user maybe from themselves) yet.
#
# Quote from Nick Jones <carpaski@gentoo.org>, who in my opinion
# knows what he is talking about:
#
# People really shouldn't force code-specific options on... It's a
# bad idea. The -march options aren't just to look pretty. They enable
# options that are sensible (and include sse,mmx,3dnow when apropriate).
#
# The next command strips CFLAGS and CXXFLAGS from nearly all flags. If
# you do not like it, comment it, but do not bugreport if you run into
# problems.
#
# <azarah@gentoo.org>
wenn ihr mir schon nicht glaubt, dann wenigstens diesen herren..???.
ich persönlich habe ein falsches verhalten des gcc 3.x bisher nur bei -march=pentium4
gesehen, deswegen mein obiger vorschlag
und nicht zuletzt aus diesen grünedn wird derzeit überlegt, C[XX]FLAGS für jedes package neu zu definieren. ( im ebuild selbst )
also von den globalen einstellungen wie bisher wegzugehen.
so, schönen abend noch
rootshell
hi,
darf ich also mal festhalten:
1) exerimentelles ebuild mach ich heute abend, denke ich -
werde es mal morgen nachmittag / abend hier zum dl bereitstellen...
dieses wird _ausschliesslich_ als neuerung die sed-befehle beinhalten, zu diesem zeitpunkt.
2) optimierung:
ok, wenn nicht gewünscht - aber zumindest die -march=pentium4 gebe ich hier zu bedenken...
diese sollte man zum jetzigen zeitpunkt (gcc-version) abfangen.
wenn nicht gewünscht - isses mir auch egal
3) gui:
das obige png hab ich per dialog durchgezogen - prinzipiell die geliche masche, wie make menuconfig der kernelconfig.
denkbare sprachen wären hierfür noch c / dialog / perl...
wobei ich c für "mit atombomben auf fliegen schiessen" halten würde.
meine favoriten wären diaolg oder perl... ( comments? )
starten der gui _selbstverständlich_ rein fakultativ ( über z.b. VDR_OPTS="enable_gui" )
wie schon oben erwähnt.
natürlich wäre das ( wie von henning schon gesagt ) noch weit in der ferne...
4) plugins
plugins als separate ebuilds - ist auch ok.
allerdings sollte nach einem neubau des vdr zumindest darauf hingewiesen werden, dass es empfehlenswert ist, sämtliche module neu zu übersetzen. einfach aus dem von mir oben schon angesprochenen grund + aus prinzipiellen stabilitätsgründen.
der zusätzliche zeitauwand für einen neubau hielte sich ja auch in grenzen bei den derzeitigen plugingrössen, denke ich; auch hier: comments???
gruss
rootshell
hi,
klar, auch sowas ist möglich und denkbar.
( eigentlich eine sehr gute idee... )
hmm, nochwas:
hab grad erfajren, dass ich bis ende der woche in münchen sein werde....
wann ich dazu komm, das neu ebuild hier reinzustellen... ????
su
viel spass noch
rootshell
hi,
also an folgendes hätte ich gedacht:
klar, die GUI soll ( wird auch bei mir schon ) von dem ebuild gestartet.
dieses kann man (natürlich) auch fakultativ machen, z.b. über VDR_OPTS="enable_gui" oder ähnliches.
die GUI sollte die gewählten VDR_OPTS nach /etc/make.conf schreiben.
d.h. ein emerge -u world würde ganz normal durchlaufen, da ja die GUI in dem falle nicht gestartet würde.
( fehlende "enable_gui" )
das ebuild würde die gespeicherten VDR_OPTS hier aus /etc/make.conf holen...
an die möglichleit, /etc/vdr.*.conf zu editieren hatte ich noch gar nicht gedacht...
ausserdem würde ich dann sämtliche plugins direkt ins haupt-ebuild integrieren; d.h.
sämtliche patches zum anpassen der plugins fielen weg, da sie ja zur bauzeit des vdr gebaut würden.
( im verzeichnis ./PLUGINS/src/[pluginname] entpackt und gebaut)
der code
for i in $(ls ${S}/PLUGINS/src) ; do
cd ${S}/PLUGINS/src/${i}
make all ||die "compile problem plugin: ${i}"
der derzeitigen ebuilds würde sowas jetzt schon ohne probleme gestatten + durchziehen - er geht ja einfach
in jedes verfügbare verzeichnis unter ./PLUGINS/src und ruft make all auf.
ob hier 3 plugins oder 27 liegen ist ziemlich egal...
da ja einige plugins direktiven wie
#HAVE_BEAUTYPATCH
o.ä. haben, sollte nach einem neubau des vdr sowieso ein neubau der plugins erfolgen...
die VDR_OPTS müssten dazu natürlich erweitert werden, um die plugins mit einzuschliessen
( VDR_OPTS="elchi ac3 scanner mplayer tvtv" ) sowas in der art.
die URL's zu den plugins könnten sehr einfach in ein separates plugins file in ./files integriert werden.
nach dem neuerscheinen eines plugins müsste dann nur die url zur neuen version eingetragen werden, sonst nix.
wieder:
keine patch-anpassungen mehr nötig, VDR_OPTS direkt nach /etc/make.conf
GUI fakultativ; bei einem update natürlich _nicht_zu starten.
aaaber:
das ist jetzt wirklich _nur_ was ich mir vorstellen würde (könnte)
und würde in letzter konsequenz wohl sowas wie einen linvdr für gentoo bedeuten...
so'n shit...
muss jetzt nach münchen fahren...
wenn ich mir die strassen so anseh - mir graust...
schönen abend noch an alle...
sagt mir einfach, was ihr davon haltet
gruss
rootshell
hi,
vielen dank erstmal für eure antworten...
hmm, was mir für die weiter entfernte zukunft ja eigentlich vorschwebt wäre folgendes...
und: ja, mit dem codieren habe ich schon begonnen...
bevor ich mir hier jedoch zuviel arbeit mache frage an alle:
wäre eine derartige entwickung überhaupt gewünscht???
und: ja, ein experimentelles ebuild mit obigen änderungen kommt,
heute allerdings nicht mehr...
gruss
rootshell
hi,
hat ja auch keiner behauptet...
so du deine USE flags richtig setzt, kannst du locler die cvs ubilds nehmen....
gruss
rootshell
hi,
Austrian Coder:
guckst du hier:
http://cvs.berlios.de/cgi-bin/…tsch/ebuilds/media-video/
lenke deine aufmerksamkeit auf:
em8300-libraries-cvs/
em8300-modules-cvs/
ach hätte ich fast vergessen...
deinem nickname entnehme ich, dass du codieren kannst:
mach doch folgendes:
hmm, du musst möglichkeiten ausprobieren, sollte also mit permutationen
zu machen sein...
also 0 0 0 0 0 0, 0 0 0 0 0 1, 0 0 0 0 1 1, usw,
du hast also für jedes 1, das dazukommt 6! möglichkeiten,
dann eliminierst du die doppelten, schliesslich ist es egal, ob eine NULL an der
dritten oder vierten stelle sich umdreht...
den rest kannst du dir denken...
ich habs so gemacht, den source kann ich dir leider nicht geben, weil ich meinem
vdr mittlerweile die maus, die tatstatur und das floppy weggenommen hab und er schön eingebaut im wohnzimmer im regal steht...
solange kein grösseres update ansteht oder ich was ändere bleibt er da...
aber ich hab nach einer halben stunde des versuchens dann lieber 2 stunden codiert....
musste nur noch solange die mplayer fenster wegklicken, bis ein bild kam, danach <STRG> + <C>, und an die konsole die letzte kombination ausgeben....
das schafft du schon, kleiner tipp:
nimm dir einen schönen flotten standard-algo, spart zeit...
ausserdem das ganze für 2 module; denn du hast ja nur _einen_ tv-encoder...
hoffe, dich auf dumme gedanken gebracht zu haben...
gruss
rootshell
hi,
danke für deine meinumg dazu,
alternativ:
die aktuellen ( r3 ?? ) als x86 markieren, das neue als ~x86 ???
zum zweiten:
klar, statt patch ein sed-shellscript in ./files -->> wäre ok...
meinung dazu?
hi,
es geht mir um die struktur der vdr ebuilds.
hier habe ich vorschläge, die doch sehr weit gehen, deshalb der thread ( Henning: hi henning *wink* )
also:
mein erster vorschlag betrifft die funktion src_compile():
ich würde vorschlagen, diesen teil des codes:
for i in $(ls ${S}/PLUGINS/src) ; do
cd ${S}/PLUGINS/src/${i}
durch folgenden zu ergänzen:
(cd include/vdr; for i in ../../*.h; do ln -sf $i .; done)
for i in $(ls ${S}/PLUGINS/src) ; do
nun, was passiert hier?
es werden headerfiles an eine stelle gelinkt, an der sie sämtliche plugins zur compiletime erwarten und einbinden können.
dadurch wird ein grosser teil des gentoo-patches überflüssig, der nämlich, der die headerlocations anpasst.
z.b.
-#include <vdr/plugin.h>
+#include <plugin.h>
sowie auch der gentoo-scanner-patch (der ja auch nichts anderes tut)
dann:
durch neue patchsets (neuer Komplettpatch z.b.) wird vielfach ein neuer gentoo patch fällig.
mein vorschlag ist, diesen durch eine reihe von sed befehlen zu ersetzen.
warum?
nun, eine neue patchversion ( s.o.) bewirkt, dass der gentoo patch wenn überhaupt nur noch mit versatz apliied wird;
ein sed komando ist hier vielseitiger;
ich schlage folgende vor:
sed -i 's:PLUGINDIR= ./PLUGINS:PLUGINDIR= /usr/lib/plugins:' Makefile
sed -i 's:$(PLUGINDIR= /usr/lib/vdr:PLUGINLIBDIR= $(PLUGINDIR): Makefile
sed -i '/Make.config/d' Makefile
sed -i '/DVBDIR/d' Makefile
diese befehle bewirken alles, was der gentoo patch auch tut.
ein anpassen der installationsroutine des Makefiles, wie es im patch noch geschieht, ist nicht nötig, da make install
nicht aufgerufen wird.
den patch bzgl der datei vdr.c würde ich durch folgendes ersetzen:
sed -i 's:*ConfigDirectory = NULL:*ConfigDirectory = CONFIGDIR:' vdr.c
hierbei gehe ich einen anderen weg als der patch;
folglich muss auch in Makefile:
sed -i '/DEFINES += -D_GNU_SOURCE/ a\
CONFIGDIR = /etc/vdr' Makefile
sed -i '/CONFIGDIR = /etc/vdr/ a\
DEFINES += -DCONFIGDIR="$(CONFIGDIR)"' Makefile
werden.
der pfad zur konfiguration wird dann als -D übergeben, wie es für /video, den lirc support, usw schon geschieht...
und ob die verwaltung der versionsnummern ( so sie zwingend beibenhalten werden muss ) über einen patch geschehen muss??? *grins*
sed -i 's:#define SO_INDICATOR ".so.":#define SO_INDICATOR ".so":' plugin.c
sed -i 's:"%s/%s%s%s%s":"%s/%s%s%s":' plugin.c
sed -i 's:LIBVDR_PREFIX, s, SO_INDICATOR, VDRVERSION);:LIBVDR_PREFIX, s, SO_INDICATOR);:' plugin.c
machts möglich... *grins*
fazit:
keine gentoo patches mehr nötig, auf ein neuerstellen und anpassen kann verzichtet werden.
bisherige funktion der ebuilds ist gegeben.
es ist nur weniger aufwand, wenn neue patches herauskommen und der gentoo-patch angepasst werden muss.
mit der bitte um eine rege diskussion
gruss
rootshell
hi,
Austrian Coder:
leider ist es ab-so-lut zwecklos, dir meine einstellungen zu geben...
jede karte benötigt andere, sorry...
und:
ich hatte absolut kein glück mit PAL -> zum glück gibts ja noch NTSC
wenn alle stricke reissen, stell die em8300 auf NTSC , der TV muss dann auch umgestellt werden - klar...
jedenfalls ging es bei mir _nur_ mit NTSC...
viel glück
umstellen der karte mit
em8300setup -n
und mad:
vielleicht wars ja auch NTSC... *grins*
rootshell
hi,
erstmal glückwunsch zur dxr3...
so, bei der dxr3 gibt es folgende problematik:
wenn du die version 0.13 der treiber installiert hast - runter damit...
ersetzen durch die cvs verion -> ebuilds im tree...
dann:
vergiss modprobe - erstmal...
die module, die du brauchst sind:
adv717x.o
bt865.o
em8300.o
jedes erstmal über insmod zu laden;
( in dieser reihenfolge...)
dann:
jedes dieser module nimmt verschiedene parameter an, die du mit insmod übergeben kannst
wobei:
adv717x:
swap_redblue_pal
pixeldata_adjust_ntsc
pixeldata_adjust_pal
pixelport_16bit
pixelport_other_pal
color_bars
bt865.o
rgb_mode
color_bars
em8300.o
activate_loopback
bt865_ucode_timeout
use_bt865
dicom_fix
dicom_control
dicom_other_pal
wobei gilt: parameter=[0|1]
bei der dxr3 gilt es zunächst, mittels empirischer versuche herauszufinden, in welcher kombination ein bild
auf dem s-vhs ausgang der karte erscheint:
du würdest also zuerst versuchen, die module per shellscript zu laden:
[code
]insmod adv717x.o pixelport_16bit=1 pixelport_other_pal=0 swap_redblue_pal=0 color_bars=0
insmod bt865.o color_bars=0
insmod em8300.o use_bt865=0 bt865_ucode_timeout=1 dicom_fix=0 dicom_control=0 dicom_other_pal=0
[/code]
noch wichtig:
es kann eine karte entweder einen bt865 oder adv717x haben - sind beides tv-encoder...
welchen du hast --> karte anschauen ode lspci
jetzt ist es ratsm zu überprüfen, ob die gerätknoten erstell worden
( /dev/em8300* )
dann
wichtig ist es, nach dem laden der treiber (kontrolle mittels dmesg) ist der risc prozessor der karte zu
programmieren:
dazu führst du an der konsole das programm
em8300setup
aus
jetzt ist die karte vollständig initialisiert.
als ersten test nimmst du _nicht_ den vdr, sondern den mplayer her
( den du _nach_ dem emergen der em8300 treiber neu übersetzt, denn dann hast du ein -vo dxr3 )
und versuchst, ein video über die dxr3 auszugeben ( eben mittels -vo dxr3 )
wenn du ein video siehst, sound hörst, gückwunsch, wenn dein bidschirm grün ist, verzerrt, usw,
musst du die module entladen ( rmmod )
und neu laden mit anderen modulparametern
danach den microcode in die dxr3 uploaden, mplayer starten, bild überprüfen, usw...
dieses wiederholst du solange, bis du ein bild hast...
danach wird der vdr noch immer nicht mit der dxr3 laufen, denn das OSD der dxr3 wird erst initialisiert, wenn ein
stream vom vdr kommt; i.a. ist das erst nach dem beenden des lernmodus.
um diesen zu überspringen, musst du entweder den vdr mit OSD_DEBUG übersetzen und ihn hier ausführen, oder ihm schon eine
funktionierende remote.conf in das konfigurationsverzeichnis legen.
dass gleichzeitig der lircd dämon gestartet sein muss ist klar... ( im falle lirc )
im falle kbd musst du die ( ?setup.conf? ) so anpassen, dass der vdr seine befehle vom keyboard annimmt
sobald der vdr den ersten stream sendet, hast du ein OSD und den screen auf dem TV-out der dxr3
hoffe, geholfen zu haben
gruss
rootshell
hi,
immer noch falsch gewählte USE flags...
mach mal ein
emerge -pv vdrplugin-dxr3
dan siehst du klarer...
da ist immer noch eine abhängigkeit, die X erfordert, und die du nicht abgefangen hast durch ein _minus_
gruss
rootshell