Aufräumen bei startup-scripts und lirc-scripts

Das Original Benutzerinterface Neutrino-SD incl. zapit, sectionsd, yWeb etc...
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Aufräumen bei startup-scripts und lirc-scripts

Beitrag von Barf »

Die startup-scripte und relatierte Lirc-funktionalität gehören sicherlich zu den coolsten features in Neutrino. Leider ist z.Z. die Namensvergebung recht zufällig, und auch die Situationen wo es ein (shell-)Skript gibt, und wann ein Lirc-skript. Z.Z. ist ausserdem die Formatumschaltungskripte (16:9.start, 4:3.start) "ausgeschalten"

Code: Alles auswählen

#if 0   /* todo: fix. probably outside of video.cpp. */
        static int last_videoformat = AVS_FNCOUT_EXT43;
        if (format != last_videoformat) {
                switch (format) {
                case AVS_FNCOUT_EXT169:
                {
                        execute_start_file(FORMAT_16_9_FILE);
                        CIRSend irs("16:9");
                        irs.Send();
                        last_videoformat = format;
                        break;
                }
                case AVS_FNCOUT_EXT43:
                {
                        execute_start_file(FORMAT_4_3_FILE);
                        CIRSend irs("4:3");
                        irs.Send();
                        last_videoformat = format;
                        break;
                }
                default:
                        break;
                }
        }
#endif

Ausserdem gibt es Probleme mit der Organisation des Codes.

Ich habe mich ein Bisschen Gedanken gemacht, hier ein erster, unvollständiger Entwurf. Die einzige Funktion der Klasse irsend wird in liblircdclient eingefügt (als static Gliedfunktion), mit einer dlopen geeigneter aufruf. Es wird dlopen benutzt um liblircdclient (falls vorhanden) zu öffnen, anstatt mit der Library zu linken -- unabhängig von ENABLE_LIRC.

Code: Alles auswählen

	void *lirc = dlopen("liblircdclient.so.0", RTLD_NOW);
	if (lirc)
	{
		printf("[neutrino] liblircdclient was found, lirc will be enabled.\n");
		*(void **) (&lirc_send) = dlsym(lirc, "send_tuxbox_lirc");
	}
	else
		printf("[neutrino] liblircdclient was not found, lirc will be disabled.\n");

Code: Alles auswählen

	if (lirc_send)
	{
		if (verbose)
			printf("[neutrino] lirc_send(%s)\n", filename);
		(*lirc_send)(filename);
	}
	else
		if (verbose)
			printf("[neutrino] lirc_send is zero\n");

Dadurch wird der bedingte Kompilierung (#ifdef ENABLE_LIRC) nicht mehr erforderlich, sondern das Programm untersucht während Runtime falls LIRC vorhanden ist. LIRC wird dadurch eine nachinstallierbare Komponente.

execute_start_file ruft jetzt sowohl eventuell vorhandene shellscripts als auch lircscripts auf. Mehr ausführlich: Der Aufruf execute_start_file(NEUTRINO_STANDBY_START_SCRIPT) (wobei NEUTRINO_STANDBY_START_SCRIPT expandiert zu "standby-start") ruft (falls vorhanden) den Programm ("Script") /var/tuxbox/config/standby-start sowie lirc-t (falls vorhanden) /var/tuxbox/config/lirc/standby-start.lirc. Dadurch gewinnt man einheitlichkeit, verliert aber Rückwärtskompatibilität.

Der Patch ist unvollständig (z.B. fehlt fix für dein pictureviewer). Bitte um Feedback.

In Patch nicht enthalten: Entfernen der beiden irsend-Verzeichnisse,

Fragen:

- Volume mit LIRC, ist es wirklich sinnvoll?
- Umbenennung der startscripte/lircscripte: Betrifft relativ wenige, und diese User sind Powerusers.
- Fixen von 16:9.start/4:3.start (seife?)
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Aufräumen bei startup-scripts und lirc-scripts

Beitrag von rhabarber1848 »

Barf hat geschrieben: *(void **) (&lirc_send) = dlsym(lirc, "send_tuxbox_lirc");
Mit gcc4 kommt diese Warnmeldung:

Code: Alles auswählen

cc1plus: warnings being treated as errors
zapit.cpp: In function 'int main(int, char**)':
zapit.cpp:3327: warning: dereferencing type-punned pointer will break strict-aliasing rules
Folgender Code kompiliert, ob er korrekt ist, weiß ich nicht:
*(void **) *(&lirc_send) = dlsym(lirc, "send_tuxbox_lirc");
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Aufräumen bei startup-scripts und lirc-scripts

Beitrag von rhabarber1848 »

Hi,
Barf hat geschrieben:Dadurch wird der bedingte Kompilierung (#ifdef ENABLE_LIRC) nicht mehr erforderlich, sondern das Programm
untersucht während Runtime falls LIRC vorhanden ist.
ich finde die Idee gut und würde sogar noch weiter gehen und die
cdk/configure-Option --enable-lirc für Neutrino komplett entfernen.
Damit wird der LIRC-Code immer in Neutrino kompiliert und liblircdclient.so
wird in jedem Image nachrüstbar, sofern mklibs.py keinen Strich durch die
Rechnung macht, wenn liblircdclient.so vorher per customization entfernt
wurde (noch zu testen).
Barf hat geschrieben:Der Patch ist unvollständig (z.B. fehlt fix für dein pictureviewer).
Lokal, auch für esound.cpp, bereits erledigt.
Barf hat geschrieben:- Volume mit LIRC, ist es wirklich sinnvoll?
Ja, damit eine Fernbedienung weiterhin ausreicht.
Barf hat geschrieben:- Umbenennung der startscripte/lircscripte: Betrifft relativ wenige, und diese User sind Powerusers.
OK
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: Aufräumen bei startup-scripts und lirc-scripts

Beitrag von rhabarber1848 »

Barf hat geschrieben:Es wird dlopen benutzt um liblircdclient (falls vorhanden) zu öffnen, anstatt mit der Library zu linken
Das führt afaics dazu, dass mklibs.py die Datei liblircdclient.so wegrationalisiert :(
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Re: Aufräumen bei startup-scripts und lirc-scripts

Beitrag von Barf »

rhabarber1848, nett dass du meine fast ein-einhalb Jahre alte Beitrag gelesen hast. :up: Es liegt eine gewisse Arbeit hinter, und falls Feedback ausbleibt... :cry:

Zum Inhalt:

Code: Alles auswählen

*(void **) (&lirc_send) = dlsym(lirc, "send_tuxbox_lirc");
Habe ich wirklich so eine Horrorcode geschrieben? :oops: Wahrscheinlich habe ich irgendwo abgekuckt.... :-? :oops: Besser (sowohl für Logik, Lesbarket und Korrektheit) wäre

Code: Alles auswählen

lirc_send = (bool(*)(const char*)) dlsym(lirc, "send_tuxbox_lirc");
oder mit einem typedef

Code: Alles auswählen

typedef bool (*lirc_send_t)(const char*);
lirc_send = (lirc_send_t) dlsym(lirc, "send_tuxbox_lirc");
rhabarber1848 hat geschrieben:Barf hat geschrieben:
- Volume mit LIRC, ist es wirklich sinnvoll?

Ja, damit eine Fernbedienung weiterhin ausreicht.
Naja, jede vernünftige (universal-)fernbedienung hat "Volume punch thru" oder ähnliges ("Activeties"). Aber in diesem Zusammenhang schadet es wohl nicht, eher bekommt man die möglichkeit sowas (sinnvoll oder nicht) zu verallgemeinern z.B. zu IP-Steuerung von AR-Receivers wie Denon und Yamaha.
rhabarber1848 hat geschrieben:ich finde die Idee gut und würde sogar noch weiter gehen und die
cdk/configure-Option --enable-lirc für Neutrino komplett entfernen.
Die configure-option wurde dann das Builden von liblircdclient.so ein/ausschalten.
rhabarber1848 hat geschrieben:Das führt afaics dazu, dass mklibs.py die Datei liblircdclient.so wegrationalisiert :(
Anderes ausgedruckt: mklibs.py ist nicht dlopen-aware. Können wir sicherlich fixen, mehr oder wenig elegant.