Zitat aus einer Antwort auf meine genannte Frage:
"Now the state DVB drivers on linux is a very sorry one and the fact that
these drivers are unmaintained stems from the fact, that the maintainer
of this subsystem is "interesting" to work with, at least and thus most
of the driver maintainers just stopped maintaining their stuff is a
different story."
Hm, die Zusammenarbeit mit dem Typen (Mauro?) ist offenbar "interessant" 8-(
Ich bin sicher, daß Du hier im Portal mindestens ein halbes Dutzend User findest, die zu „interessant“ eine ganz eigene Geschichte beisteuern können…
Nicht umsonst wird für diverse beliebte Hardware abseits vom Kernel entwickelt…
So, ich habe mal meine Angebetete angestupst. Die hat dann mal den Hans Verkuil in der Mailingliste angesprochen. Daraus entspann sich folgender, evtl. auch für hier interessanter Dialog.
Fazit: Der Patch wurde vorläufig gedropped. Ob jetzt Jemand dem Hans folgt/folgen kann, was dessen Vorschläge anbelangt, liegt natürlich nicht in meiner Entscheidung.
Hi ...,
...
I've dropped the PR for now. Is the concern specifically for the saa7146
based hardware?I.e., from Red Hat's point of view, are there any concerns about removing
vpfe_capture, tm6000, zr364xx, stkwebcam, fsl-viu, cpia2 and meye?The core problem with saa7146 (and the other deprecated drivers) is that
it is using the old videobuf framework, which has known problems and we
want (need!) to get rid of it, either by dropping drivers or converting
them.One partial solution would be to drop analog video support from saa7146,
since that's the bit that uses this framework. DVB would remain working,
but analog video support would die, unless someone steps up to do the
conversion from vb1 to vb2.So support for the old MXB, Hexium Gemini and Hexium Orion would die, but
for the other DVB devices it would stay alive.I'm honestly quite surprised that these old DVB PCI cards are still in
use, I did not expect that.Regards,
Hans
Ciao.
Michael.
Dann stellt sich noch die Frage, ob Jemand "the old MXB, Hexium Gemini and Hexium Orion" braucht oder ob die raus können, wie Hans geschrieben hatte.
Es geht aber nur um den saa7146 und die budget-Treiber? Oder hat er auch die Entfernung von av7110 gestoppt?
Es ging um
https://www.spinics.net/lists/linux-media/msg224902.html
und da ist der av7110 auch aufgelistet.
Ich stecke allerdings nicht in der Kernelentwicklung und weiß im Regelfall auch nicht, welcher Treiber nun für was genau ist.
Wofür genau ist der av7110?
Der av7110 enthält die Decoderfunktionen für die SD-FF-Karte. Das Problem ist hier, dass die verwandte API als deprecated gilt. Alle anderen Treiber, darunter der saa7146, benötigen 'nur' eine Conversion auf vb2. Wobei ich die Idee, stattdessen den analogen Support aus dem Treiber zu nehmen, auch für eine tragbare Idee halte. Falls der av7110 dennoch gelöscht wird, müsste der ttpci-Treiber für die FF-Karte so umgebaut werden, dass die Karte keine Decoderfunktionen mehr hat und als reine Tunerkarte weiterverwandt werden kann.
Nochmal zur Klarstellung: Es geht hier um zwei verschiedene paar Schuhe. Die Mehrzahl der Treiber soll nur wegen der fehlenden vb2-Umstellung gelöscht werden. Da gibt es ansonsten kein großes Konfliktpotential, es hat halt nur niemand gemacht. Beim av7110 und der Decoder-API schwelt der Konflikt hingegen schon seit Jahren und hatte seinerzeit u.a. zum Rückzug von UFO als Maintainer geführt.
Naja, irgendwie hört sich für mich die Idee tragfähig an, den analogen Support raus zu nehmen, wenn dafür alles Andere funktionsfähig bleibt.
Wenn alle hier einverstanden sind, könnten wir das dem Hans so antworten.
wenn dafür alles Andere funktionsfähig bleibt.
wie gesagt, ohne av7110 könnte die FF-Karte nicht mehr als Ausgabedevice benutzt werden
Der av7110 enthält die Decoderfunktionen für die SD-FF-Karte.
Zur Sicherheit nochmals die Nachfrage:
Das ist analog und würde mit Abschaltung der Analogfunktionen nicht mehr laufen?
Oder das würde nur dann nicht mehr laufen, wenn der av7110 rausfliegt?
Wenn nur die Analogfunktion rausfliegt und der av7110 weiter als deprecated drinbleibt, müsste die FF-Karte weiterhin als Ausgabedevice möglich sein. Es kann aber sein, dass Anpassungen am dvbsddevice-Plugin notwendig sind. Ich bin nicht sicher, ob der Code zum Grabben z.B. Analogcode verwendet.
Wenn der Analogcode aus saa7146 rausfliegt und av7110 gelöscht wird, kann die FF-Karte nur als Tuner und nicht mehr zur Ausgabe benutzt werden.
Gerade nachgesehen:
Die Funktion Grabimage im dvbsddevice-Plugin nutzt V4L2-Code:
uchar *cDvbSdFfDevice::GrabImage(int &Size, bool Jpeg, int Quality, int SizeX, int SizeY)
{
if (devVideoIndex < 0)
return NULL;
char buffer[PATH_MAX];
snprintf(buffer, sizeof(buffer), "%s%d", DEV_VIDEO, devVideoIndex);
int videoDev = open(buffer, O_RDWR);
if (videoDev >= 0) {
uchar *result = NULL;
// set up the size and RGB
v4l2_format fmt;
memset(&fmt, 0, sizeof(fmt));
fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
fmt.fmt.pix.width = SizeX;
fmt.fmt.pix.height = SizeY;
fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_BGR24;
fmt.fmt.pix.field = V4L2_FIELD_ANY;
if (ioctl(videoDev, VIDIOC_S_FMT, &fmt) == 0) {
v4l2_requestbuffers reqBuf;
memset(&reqBuf, 0, sizeof(reqBuf));
reqBuf.count = 2;
reqBuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
reqBuf.memory = V4L2_MEMORY_MMAP;
if (ioctl(videoDev, VIDIOC_REQBUFS, &reqBuf) >= 0) {
v4l2_buffer mbuf;
memset(&mbuf, 0, sizeof(mbuf));
mbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
mbuf.memory = V4L2_MEMORY_MMAP;
if (ioctl(videoDev, VIDIOC_QUERYBUF, &mbuf) == 0) {
int msize = mbuf.length;
unsigned char *mem = (unsigned char *)mmap(0, msize, PROT_READ | PROT_WRITE, MAP_SHARED, videoDev, 0);
if (mem && mem != (unsigned char *)-1) {
v4l2_buffer buf;
memset(&buf, 0, sizeof(buf));
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buf.memory = V4L2_MEMORY_MMAP;
buf.index = 0;
if (ioctl(videoDev, VIDIOC_QBUF, &buf) == 0) {
v4l2_buf_type type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
if (ioctl (videoDev, VIDIOC_STREAMON, &type) == 0) {
memset(&buf, 0, sizeof(buf));
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buf.memory = V4L2_MEMORY_MMAP;
buf.index = 0;
if (ioctl(videoDev, VIDIOC_DQBUF, &buf) == 0) {
if (ioctl(videoDev, VIDIOC_STREAMOFF, &type) == 0) {
// make RGB out of BGR:
int memsize = fmt.fmt.pix.width * fmt.fmt.pix.height;
unsigned char *mem1 = mem;
for (int i = 0; i < memsize; i++) {
unsigned char tmp = mem1[2];
mem1[2] = mem1[0];
mem1[0] = tmp;
mem1 += 3;
}
if (Quality < 0)
Quality = 100;
dsyslog("grabbing to %s %d %d %d", Jpeg ? "JPEG" : "PNM", Quality, fmt.fmt.pix.width, fmt.fmt.pix.height);
if (Jpeg) {
// convert to JPEG:
result = RgbToJpeg(mem, fmt.fmt.pix.width, fmt.fmt.pix.height, Size, Quality);
if (!result)
esyslog("ERROR: failed to convert image to JPEG");
}
else {
// convert to PNM:
char buf[32];
snprintf(buf, sizeof(buf), "P6\n%d\n%d\n255\n", fmt.fmt.pix.width, fmt.fmt.pix.height);
int l = strlen(buf);
int bytes = memsize * 3;
Size = l + bytes;
result = MALLOC(uchar, Size);
if (result) {
memcpy(result, buf, l);
memcpy(result + l, mem, bytes);
}
else
esyslog("ERROR: failed to convert image to PNM");
}
}
else
esyslog("ERROR: video device VIDIOC_STREAMOFF failed");
}
else
esyslog("ERROR: video device VIDIOC_DQBUF failed");
}
else
esyslog("ERROR: video device VIDIOC_STREAMON failed");
}
else
esyslog("ERROR: video device VIDIOC_QBUF failed");
munmap(mem, msize);
}
else
esyslog("ERROR: failed to memmap video device");
}
else
esyslog("ERROR: video device VIDIOC_QUERYBUF failed");
}
else
esyslog("ERROR: video device VIDIOC_REQBUFS failed");
}
else
esyslog("ERROR: video device VIDIOC_S_FMT failed");
close(videoDev);
return result;
}
else
LOG_ERROR_STR(buffer);
return NULL;
}Wenn der den analogen Teil des saa7146-Treibers betrifft, müsste man den Verlust der Grab-Funktion (Schnappschüsse vom laufenden Programm schießen) in Kauf nehmen. Und das Plugin (das seit Jahren obsolet ist und nicht mehr Teil des vdr-Codes) müsste angepasst werden.
Na gut, damit kann man leben, nehme ich an.
Dann schreiben wir das mal dem Hans in der Art.
Und das Plugin (das seit Jahren obsolet ist und nicht mehr Teil des vdr-Codes)
Das dvbsddevice-Plugin ist nicht mehr Teil des vdr selber, so wie alle Ausgabeplugins und viele, viele andere Plugins auch. Daraus ergibt sich in keinster Weise, dass dieses Plugin obsolet oder unbrauchbar oder nicht gewartet, oder was auch immer in dieser Art ist. Wenn Du keine SD-FF als Ausgabedevice nutzt, dann brauchst Du das Plugin nicht. Andere Leute nutzen es und sind sehr zufrieden damit.
Wenn fuer die Grab-Funktion eine vb2-Konvertierung notwendig ist, wuerde ich die gerne machen. Natuerlich nur, wenn der av7110 aktiv bleibt und irgendwas decodiert, was man auch grabben kann. Andere Analog/Hybrid-Funktionen des saa7164 benutze ich nicht, kann ich nicht testen, koennen von mir aus gerne entfernt werden.
Wie schon oben steht, wenn jemand irgendwas zu dem Thema an die Mailingliste schreibt, mich bitte auf Cc: setzen.
Gruss,
S:oren
[...]Wie schon oben steht, wenn jemand irgendwas zu dem Thema an die Mailingliste schreibt, mich bitte auf Cc: setzen.
Gruss,
S:oren
Haben wir jetzt leider nicht gemacht, aber wenn du die Beiträge von heute auf der Mailingliste mal lesen magst, da findest du all das, was ich auch oben zusammengefasst habe.
Ciao.
Michael.
Reicht auch noch bei der naechsten Mail, oder wann immer es konkret wird...
ohne av7110 könnte die FF-Karte nicht mehr als Ausgabedevice benutzt werden
Ohne av7110 ist die FF-Karte nur noch als Türstopper nutzbar.
Der DVB-Datenfluss ist:
Tuner > av7110 > DP-RAM > SAA7146 > PCI
Ausnahme sind Karten mit FullTSmod.
Da geht es direkt vom Tuner zum SAA7146.
Aber auch die werden wohl nicht laufen.
Wenn ich das noch recht erinnere, hängt der Tuner bei der FF am I2C vom av7110.
Nicht wie bei der Budget am I2C vom SAA7146.
Dann stellt sich noch die Frage, ob Jemand "the old MXB, Hexium Gemini and Hexium Orion" braucht
Den Hersteller scheint es noch zu geben und es gibt auch noch eine Seite zu der Karte:
https://hexium.hu/02_Products/DI…Page_Print.html
Ich habe so eine Karte aber noch nie gesehen.
So wie es aussieht, werden wohl eher für professionelle Anwender gewesen sein. Ich tippe mal in Verbindung mit Überwachungskameras.
Keine Ahnung mit was für Software die verwendet wurden und ob sowas aktuell noch genutzt wird.
Wenn der den analogen Teil des saa7146-Treibers betrifft, müsste man den Verlust der Grab-Funktion (Schnappschüsse vom laufenden Programm schießen) in Kauf nehmen.
Der Verlust wäre verschmerzbar, benutzt man ja seltenst. Ich meine mich auch zu erinnern, dass nicht alle Output-Plugins die Funktion unterstützt haben, bin aber nicht sicher.
Ist irgendwas von der Funktion abhängig? Mir fällt nichts ein.
Und das Plugin (das seit Jahren obsolet ist und nicht mehr Teil des vdr-Codes)
Sowohl die Karte als auch die Schnittstelle am VDR haben sich seit Jahren nicht geändert.
Mir fällt bei besten Willen kein Grund ein, warum man dann am Plugin was ändern sollte.
Für mich ist das nicht gleichbedeutend mit "obsolet", ich würde den Zustand eher als "stable" bezeichnen.
Nach meiner Erinnerung war die FF-Karte zuletzt ohne FullTS Mod nur noch im Transfer-Mode nutzbar, nachdem die SD-Sende im Zuge einer Qualitätsoffensive der öffentlich-rechtlichen Sender ihre Datenrate auf 8MBit/s und mehr hochgeschraubt haben. Wenn auch der Transfermode ohne av7110 nicht geht, ist das natürlich ein starkes Argument dafür, den av7110 in staging zu belassen.
Mal angenommen, auch der av7110 bleibt wie er ist weiter in staging und in saa7146 wird der Analogcode entfernt. Im besten Fall kompiliert dvbsddevice dennoch, weil die Definitionen für die beim Grabben verwandten ioctls nicht aus saa7146, sondern videodev2.h inkludiert sind. Dann gibt es lediglich einen error beim Versuch, das analoge videodevice zu öffnen. Ob das erst beim Grabben oder schon beim Initialisieren des Plugins geschieht, müsste man genauer prüfen. Besser wäre es jedenfalls, den Grabbing-Teil im Plugin rauszunehmen um Fehler zu vermeiden.
Don’t have an account yet? Register yourself now and be a part of our community!
