Epson DX4400 - Driver proprietari

[joe]

Continuo qui in questo topic con titolo corretto quanto già iniziato a raccontare.
In sintesi, vorrei far funzionare la stampante in oggetto colo suo driver proprietario, perché quello open gutenprnt non la gestisce in modo accettabile (estrema lentezza, troppo consumo inchiostro, inchiodamenti sistematici ecc...).
Il problema è che i driver closed rilasciati da Epson sono roba vecchissima, circa 2008 o giù di lì e per il momento non sono riuscito a compilarli sulla slack 15 del 2025.
Per aggirare il problema ho sfruttato una VM con win7, lì il driver è ottimo e grazie a libvirt, virt-manager e il reindirizzamento USB verso la VM, di fatto la stampante viene gestita direttamente da windows virtualizzato. È un ripiego ovviamente ma funziona.

Da un'altra discussione era saltata fuori l'idea di tentare l'installazione dei driver su un sistema virtuale linux, ma vecchio e da lì poi carpire un file PPD da riutilizzare in qualche modo direttamente con la slackware attuale.
Allora ho preso spunto da questa vecchia discussione del 2008, in cui i driver sembrano funzionanti con qualche correzione che l'utente di allora ha lì condiviso:

Vecchia discussione del 2008 su installazione driver Epson

Così mi sono creato una VM con Slackware-12.1. Ho fatto qualche tentativo e lì alcune cose compilano, mentre sulla 15.0 ovviamente danno errore, probabilmente perché le versioni del compilatore librerie ecc non sono più compatibili.
Ho descritto un po' di stranezze che sono saltate fuori durante anche il solo trasferimento dei pacchetti dei drivers dal sistema host al guest. Per non ripetermi metto i link all'altra discussione che aveva un titolo non inerente:

viewtopic.php?p=360680&sid=8dc93ba70053 ... 5f#p360680

Giusto per ricapitolare i pacchetti da installare sarebbero due:

Codice: Seleziona tutto

pips-3.0-1.src.rpm
pips-scx4450-FedoraCore5-3.0-CLGE.tgz

Il primo prevede la compilazione dei simil-sorgenti di questa roba, un sotto pacchetto chiamato "pips-common" in particolare. Purtroppo non sono riuscito a lavorarlo interamente sulla VM, perché all'atto della scompattazione se ne perde metà per strada. Forse è un errore dovuto alla virtualizzazione? non lo so... fatto sta che per aggirare il problema ho convertito il pacchetto rpm delle pips-common sulla macchina "host 15.0", e poi ho trasferito il targz sul guest 12.1, così sembra funzionare sia li trasferimento che la successiva compilazione ed installazione. Ne ho fatto un pacchetto slackware alla fine e ho installato quello.

Anche il secondo pacchetto non si riesce a trasferire. Ho provato a cambiare i permessi del file a 755 ma niente... non saprei. Comunque è un tarball tgz contenente un eseguibile "ibrido", in parte è uno script ma in parte è comprensivo di vari binari tra cui degli rpm direttamente assemblati nello stesso file:
[/code]
-rwxr-xr-x 1 502 502 1,4M dic 20 2019 pips-scx4450-FedoraCore5-3.0-CLGE.install*
-rwxrwxrwx 1 root root 1,4M set 3 10:31 pips-scx4450-FedoraCore5-3.0-CLGE.tgz*
[/code]

Codice: Seleziona tutto

pips-scx4450-FedoraCore5-3.0-CLGE.install: POSIX shell script executable (binary data)

Mi viene in mente che non ho provato a cambiare i permessi e proprietario del file, forse un chown root:root e chmod 755 potrebbe far rientrare l'errore di trasferimento.
È un errore stranissimo: se tento di spostarlo via ssh scp o simili dall'host al guest, l'intera rete virtuale generata da libvirt va in crash e i due sistemi non comunicano più completamente. Il trasferimento nel frattempo resta tipo al 10% e anche lui si blocca lì misteriosamente. Boh... non so neanche se sia un problema di permessi o cosa.

Ad ogni modo il file .install si può installare su una directory target invece che in root, di fatto scompattandolo, e salta fuori il suo contenuto che comprende degli rpm.
Questi manifestano lo stesso problema dell'altro pacchetto: la slack-12.1 virtuale per qualche santo non riesce a gestirli, scompattandoli se ne perde dei pezzi per strada e di conseguenza l'installazione va a ramengo.
Questo pacchetto non prevede la compilazione di nulla, è solo una estrazione di files e installazione in varie dirs con qualche script che viene eseguito qua e là.
Allora ho provato ad estrarre tutto sulla 15.0 ne ho fatto uno slackbuild mettendo in doinst.sh gli script di postinstall e aggiungendo qui il suggerimento che dava il vecchio utente slacky.

Ho creato insomma un tgz slackware installabile.
L'ho trasferito sul guest, questa volta senza problemi... evidentemnte c'entrano qualcosa i permessi dei files e la presenza di rpm...
E alla fine l'ho installato sulla 12.1.

Ora, il problema è che si dovrebbe avviare un demone chiamato:

Codice: Seleziona tutto

ekpd

Cje si dovrebbe trovare piazzato in:

Codice: Seleziona tutto

/etc/rc.d/init.d/ekpd

In realtà lì non c'è, si trova in altra directory, per cui si può anche copiare lì e alla fine farlo partire a mano, ma si può mettere anche in una dir più consona a slackware:

Codice: Seleziona tutto

/etc/rc.d/ekpd start

Può anche essere che il mio slackbuild, andando ad estrarre gli rpm salti qualche passaggio e ometta l'esecuzione di alcuni script intermedi che potrebbero legare gli eseguibili in qualche modo.
Ad ogni modo se provo ad avviare il demone, non ritorna errore, ma dando poi un'occhiata con pgrep, non risulta in esecuzione.
E avviando poi l'altro programma "ekpsmt" che se ho ben capito serve per impostare la stampante... dice che il demone ekpd non è in esecuzione e deve essere avviato ecc...
In pratica ekpd lo si avvia ma in qualche modo se ne esce subito e non sta in ascolto.

Boh, lo stato dell'arte al momento è questo. Qualche pezzo del driver sembra eseguire qualcosa, ma niente di funzionate.
Sarei tentato di provare l'installazione in modalità più canonica, anche su slackware si può fare come dimostra il vecchio utente che ha riportato un'installazione riuscita. Ma non mi spiego perché la mia installazione della vecchia slack in virtuale presenti le problematiche di gestione degli rpm presenti nei pacchetti driver.
Che non siano problemi di compatibilità tra libvirt moderna e questi sistemi molto più vecchi? Mi sembra strano ma ne sapete nulla di problematiche simili?

Potrei provare direttamente ad installare una fedora 9 e vedere cosa succede. In teoria quei pacchetti dovrebbero filar via lisci.
Boh se avete qualche suggerimento, sempre benaccetto!

[joe]

Dunque, ieri sera poi sono riuscito a fare qualche prova, quella che avevo accennato: tentativo installazione pacchetti epson su fedora 9.
Per cui, messa su altra VM, Scaricato DVD fedora 9 (fortuna che ci sono ancora mirrors per quella roba e fortuna che con aria2c si possono sfruttare i downloads in parallelo).
Ho creato il disco virtuale in formato qcow2. E poi va be' via virt-manager ho seguito il solito wizard, mettendo però DVD e storage come SATA invece che "virtio", magari per linux non ci sono problemi ma se poi manca un driver o roba simile...
Una nota, come CPU ho lasciato il "passthrough". Lo specifico perché mi stanno venendo dei dubbi in merito, ne parlerò dopo.

Alla fine tutto OK sistema installato, rete OK ecc. Come normale, c'è il solito problema dei ca-certificates di sistema scaduti da secoli.
Per cui invece di scaricare i pacchetti dal sito epson ho fatto di nuovo il giochino del serve http sul sistema host slackare (python -m htttp.server) che fa scaricare i files della directory corrente dalla porta 8000.
OK, i due pacchetti pronti sul desktop di gnome su fedora:

Codice: Seleziona tutto

pips-3.0-1.src.rpm
pips-scx4450-FedoraCore5-3.0-CLGE.tgz

Il primo necessita di librpm di versione diversa da quella di sistema. Se ho ben capito le vorrebbe più vecchie.
Il secondo, si riesce a scompattare i ltarball che contiene l'eseguibile ibrido:

Codice: Seleziona tutto

pips-scx4450-FedoraCore5-3.0-CLGE.install

Provo ad avviarlo e se ne esce con un errore di permessi per il file "UserManual.txt", e si ferma lì, non si installa un tubo.
Insomma, per fortuna che erano pacchetto per Fedora!

Siccome i ferro era caldo... ho fatto un altro tentativo con un sistema ancora più vecchio, "Fedora 6".

In questo non sono neanche riuscito a far passare i pacchetti dall'host al guest.

Per la cronaca su questa ulteriore VM ho scelto lo storage in formato RAW, mi sono detto: non si sa mai che l'allocazione dinamica dello spazio crei qualche rogna a livello input output. Ipotesi pindariche eh...
E me ne viene in mente un'altra di queste ipotesi:
Siccome questi sistemi virtuali son vetusti e obsoleti, montano un kernel altrettanto vetusto e obsoleto. Scegliendo il passthrough come tipo di CPU, potrebbero avere dei problemi lato kernel a gestire il processore?

Ora, nel mio caso ho qualche dubbio che il problema sia quello perché tutti sti test li sto facendo girare su un PC altrettanto obsoleto con un "Core 2 Quad 2.66GHz"... andando a cercare però effettivamente, la CPU è stata rilasciata nel marzo 2008, mentre fedora core 6 è più vecchia di quasi 2 anni! Dell'ottobre 2006.
Chissà potrebbe essere che la cpu sia troppo recente per il kernel di fedora 6? E che quindi funzionicchi ma possa generare problemi del tipo riportato?