realizzare tablet con cellulare e schermo esterno

[PlayHard]

ELO ET1215L 7CWA 1 G 12" VGA USB Serial POS Point Sale Touchscreen Touch Monitor 741149300162 | eBay

Riprendo questa discussione per dirvi che ho trovato questa soluzione, magari a qualcuno può interessare e ad altri no, se non altro sfatiamo il mito dell' "impossibilità", anche perchè tralasciando le spese di spedizione 64$ non sono una spesa esorbitante...Comunque continuo a lavorarci per migliorare ancora questa soluzione

[diego63]

ELO ET1215L 7CWA 1 G 12" VGA USB Serial POS Point Sale Touchscreen Touch Monitor 741149300162 | eBay

Riprendo questa discussione per dirvi che ho trovato questa soluzione, magari a qualcuno può interessare e ad altri no, se non altro sfatiamo il mito dell' "impossibilità", anche perchè tralasciando le spese di spedizione 64$ non sono una spesa esorbitante...Comunque continuo a lavorarci per migliorare ancora questa soluzione

Personalmente non ho mai parlato di impresa impossibile (leggi quanto ho evidenziato sotto), ribadisco quindi che il problema rimane non il remotare il contenuto del display ma il sistema di input, ammesso e non concesso che per quella cifra ti diano qualcosa di decente, come puoi collegare via USB quel dispositivo ad uno smartphone? Bisognerebbe capire quali sistemi lo supportano e se necessita di drivers, il rischio è che se anche qualora tu riuscissi a stabilire un collegamento audio/video, dovresti comunque utilizzare lo smartphone come dispositivo di input.
Esempio... Con Windows 8 si cominciano a vedere notebook con display touch, se ad uno di questi notebook si collegasse un display anch'esso touch, quest'ultimo non potrebbe utilizzare tale tecnologia in quanto collegandolo vengono "trasportati" i soli segnali video ma non tutto ciò che serve alla sezione di input, spero di essermi spiegato

Certamente, ma l'intenzione da quello che ho capito sarebbe quella di avere un display touch esterno, il punto è che a meno di competenze straordinarie, non è possibile remotare l'input del dispositivo touch (cosa diversa dal display!!) sullo schermo remoto, input che rimane comunque appannaggio dell'apparecchio sorgente, smartphone, tablet, lettore musicale, ecc...

[diego63]

Un qualsiasi sistema touch non ha nulla a che vedere con il display in cui è contenuto, mi spiego meglio portando un esempio molto semplice...
Il display è la periferica che ci consente di vedere ciò che desideriamo vedere, il sistema touch (quindi di input) è qualcosa che "sembra" possa fare parte del display ma in realtà è un'altra periferica allo stesso modo di una tastiera/mouse, il fatto che sia "sopra" (o "sotto")al display e interagisca con esso è solo una condizione per permettere l'interazione, interazione che è proprietaria a livello di tecnologia (il touch di un iphone non funziona su un display di un altro smartphone e viceversa).
Insomma remotare un sistema touch non è come aggiungere un mouse al pc, il mouse è una periferica con sistema di input del tutto rispondente a determinati criteri unificati, un sistema touch è qualcosa di moooooolto più complesso e strettamente legato ad una precisa tecnologia...

[Ma5t3r]

Insomma remotare un sistema touch non è come aggiungere un mouse al pc, il mouse è una periferica con sistema di input del tutto rispondente a determinati criteri unificati, un sistema touch è qualcosa di moooooolto più complesso e strettamente legato ad una precisa tecnologia...

Una periferica, qualunque essa sia, ha dei driver che si occupano di ricerverne i segnali tramite un qualche canale (nell'esempio sopra, USB oppure seriale), di gestirli e di trasformarli in un output per il sistema operativo (nei sistemi unix-like, sottoforma di uno o più "file testuali").

Nel caso di Linux, i driver "fanno parte del kernel" (non è proprio così, ma per ora facciamo finta di si), per cui, nel caso dello schermo sopra, ipotizzando di poter attaccare sia l'HDMI dello schermo, sia la USB del touchscreen, e di poter disporre di driver linux-compliant, è possibile compilare il kernel includendo i driver, flashare il kernel modificato e "leggere i valori" dei tocchi sullo schermo.

Questo non porta direttamente il tutto a funzionare, o meglio, il fatto che i valori vengano letti non implica che la periferica sia riconosciuta come "schermo touchscreen" dal sistema, o come "mouse".
Molto più probabilmente sarebbe necessario anche scrivere "qualcosa" (un' app o, meglio, un modulo del kernel) che si occupi di simulare l'evento di tocco leggendo la coppia di valori passati dal driver.
Qualcosa tipo "leggo x1 e y1 passati dai driver del monitor" => "calcolo opportunamente x2 e y2 che potrebbero differire dalle coordinate corrispondenti sul monitor dello smartphone" => "simulo l'evento 'tocco su x2 e y2'" dovrebbe funzionare.

Chiaramente c'è dietro un lavoro non estremamente difficile né lungo, ma fuori dalla portata dell'utente medio; sicuramente non tale da giustificare l'esborso dei soldi per un display nuovo.
EDIT: ricordavo che l'OP avesse il display rotto, ma devo aver confuso con qualche topic letto altrove.
Se l'OP stesse studiando informatica o ing. informatica... Sicuramente si tratterebbe di un progetto valido per qualche corso / tesi .

[diego63]

Una periferica, qualunque essa sia, ha dei driver che si occupano di ricerverne i segnali tramite un qualche canale (nell'esempio sopra, USB oppure seriale), di gestirli e di trasformarli in un output per il sistema operativo (nei sistemi unix-like, sottoforma di uno o più "file testuali").

Nel caso di Linux, i driver "fanno parte del kernel" (non è proprio così, ma per ora facciamo finta di si), per cui, nel caso dello schermo sopra, ipotizzando di poter attaccare sia l'HDMI dello schermo, sia la USB del touchscreen, e di poter disporre di driver linux-compliant, è possibile compilare il kernel includendo i driver, flashare il kernel modificato e "leggere i valori" dei tocchi sullo schermo.

Questo non porta direttamente il tutto a funzionare, o meglio, il fatto che i valori vengano letti non implica che la periferica sia riconosciuta come "schermo touchscreen" dal sistema, o come "mouse".
Molto più probabilmente sarebbe necessario anche scrivere "qualcosa" (un' app o, meglio, un modulo del kernel) che si occupi di simulare l'evento di tocco leggendo la coppia di valori passati dal driver.
Qualcosa tipo "leggo x1 e y1 passati dai driver del monitor" => "calcolo opportunamente x2 e y2 che potrebbero differire dalle coordinate corrispondenti sul monitor dello smartphone" => "simulo l'evento 'tocco su x2 e y2'" dovrebbe funzionare.

Chiaramente c'è dietro un lavoro non estremamente difficile né lungo, ma fuori dalla portata dell'utente medio; sicuramente non tale da giustificare l'esborso dei soldi per un display nuovo.
EDIT: ricordavo che l'OP avesse il display rotto, ma devo aver confuso con qualche topic letto altrove.
Se l'OP stesse studiando informatica o ing. informatica... Sicuramente si tratterebbe di un progetto valido per qualche corso / tesi .

Beh lo avrebbe dichiarato fosse così e nel caso fosse così.... dovrebbe essere lui a portare risposte quì dentro, non viceversa , il forum idoneo sarebbe un'altro, se vogliamo il tutto non è che sia strettamente legato al mondo Android, l'hardware di un S3 per esempio con le opportune competenze potrebbe reggere (in teoria) qualsiasi OS ma volessi installarci UNIX (per assurdo) mi rivolgerei altrove

[diego63]

L'hardware di uno smartphone è per gran parte composto da una manciata di semiconduttori gestiti a livello di singolo chip da firmware proprietari che sovraintendono al "loro" componente, sono "consapevoli" solo ed esclusivamente di ciò che può eseguire il "loro" componente , tutto questo fa capo a ciò che chiameremo kernel, che sua volta può rispondere a drivers, scripts e via dicendo, tutto questo viene gestito in modo opportuno dall'utente attraverso un OS. In poche righe questo è il concetto che vale per qualsiasi dispositivo.
Ora... se si hanno competenze sufficienti e l'operazione da conseguire è coerente con la natura dell'hardware, è possibile arrivare a qualsiasi risultato. Quali sono i vincoli oppure i limiti?

1) Competenza
2) Economicità relativa = efficienza

Portiamo un esempio...
Voglio usare lo smartphone come torcia per illuminare:
Soluzione 1) Accendo il flash
Soluzione 2) Genero una immagine completamente bianca e mando la luminosità al massimo

Considerazioni Sia nella soluzione 1 che nella soluzione 2 non posso in alcun modo andare oltre i limiti fisici imposti dall'hardware, in sostanza non posso pretendere di illuminare come una lampada alogena da 300 watt

Allo stesso modo se voglio remotare qualcosa attraverso le porte del mio dispositivo posso farlo soltanto se fisicamente è previsto e quindi possibile poterlo fare, insomma il fatto che esista una porta non è detto che quest'ultima mi permetta di gestire qualsiasi cosa attraverso la stessa, altro esempio....
Voglio usare lo smartphone per gestire il riscaldamento di casa:
Prima devo sapere se attraverso le porte disponibili posso gestire un segnale (qualsiasi tipo di segnale) in out

[Ma5t3r]

Beh lo avrebbe dichiarato fosse così e nel caso fosse così.... dovrebbe essere lui a portare risposte quì dentro, non viceversa

Bhe, i toni della discussione finora sono stati abbastanza calmi, mi sembra .
Un po' di ostinatezza dell' OP nel voler dire che è fattibile... Per cui sono intervenuto per specificare che si, ragionevolmente è fattibile, e si può provare posto di sapere fare X e Y.

il forum idoneo sarebbe un'altro, se vogliamo il tutto non è che sia strettamente legato al mondo Android

Vero, o per lo meno, è distinguibile una parte di conoscenze di programmazione C & moduli del kernel, e una parte Android, forse nemmeno necessaria.
Sicuro per cimentarsi in un'operazione simile sarebbe sensato chiacchierare con i cuochi di XDA.

l'hardware di un S3 per esempio con le opportune competenze potrebbe reggere (in teoria) qualsiasi OS ma volessi installarci UNIX (per assurdo) mi rivolgerei altrove

Giustamente, ma almeno ora l'OP ha qualche nome e concetto in più a cui pensare .

[diego63]

...in ultimo e chiudo perchè credo di avere illustrato a sufficienza l'argomento, se si vuole fare davvero fare palestra sulla faccenda specifica.
Comunciare con un notebook con tecnologia touch, si hanno tutti i presupposti per riuscire nell'intento (previa consapevolezza di ciò che si deve fare) per ovvi motivi... si ha a disposizione di un hardware estemamente versatile, quindi con porte in/out in quantità, possibilità di interagire con un OS dotato di possibilità pressochè illimitate (windows viene usato a 360° in qualsiasi campo per qualsiasi scopo).
Se non si conseguono risultati con tale ricerca e mezzi a disposizione, direi che sarebbe del tutto inutile pensare di battere altre strade

[diego63]

Bhe, i toni della discussione finora sono stati abbastanza calmi, mi sembra .
Un po' di ostinatezza dell' OP nel voler dire che è fattibile... Per cui sono intervenuto per specificare che si, ragionevolmente è fattibile, e si può provare posto di sapere fare X e Y.



Vero, o per lo meno, è distinguibile una parte di conoscenze di programmazione C & moduli del kernel, e una parte Android, forse nemmeno necessaria.
Sicuro per cimentarsi in un'operazione simile sarebbe sensato chiacchierare con i cuochi di XDA.



Giustamente, ma almeno ora l'OP ha qualche nome e concetto in più a cui pensare .

Ma io sono estremamente calmo mi sa che hai travisato qualcosa, oppure io (in questo caso miscuso) mi sono espresso male

[Ma5t3r]

Allo stesso modo se voglio remotare qualcosa attraverso le porte del mio dispositivo posso farlo soltanto se fisicamente è previsto e quindi possibile poterlo fare, insomma il fatto che esista una porta non è detto che quest'ultima mi permetta di gestire qualsiasi cosa attraverso la stessa, altro esempio....
Voglio usare lo smartphone per gestire il riscaldamento di casa:
Prima devo sapere se attraverso le porte disponibili posso gestire un segnale (qualsiasi tipo di segnale) in out

Su questa frase non sono d'accordo.

USB è uno standard, una periferica "USB compliant" obbedisce a una serie di regole atte a certificarne un determinato comportamento.
Nel caso del N4, quindi, non ci sono assolutamente problemi sulla porta USB: qualsiasi segnale una periferica USB invii, di qualsiasi natura, questo segnale arriva al controller USB, viene "letto" e viene rigirato al kernel che interroga i suoi moduli, cercando il driver in grado di gestire il segnale della periferica X, registrato in precedenza.

Poco importa che questa periferica sia un mouse, una tastiera, una stampante, un cannone laser, fintantoché gli agenti sono entrambi USB compliant.

Del resto, dall'era del digitale e dall'usb, bastano due cavi per l'alimentazione e due cavi per il segnale, non c'è motivo di crearsi complicazioni su *quel* fronte.

Che poi ci siano i driver nel kernel per gestire la periferica X è un altro discorso, ma quelli si possono sempre scrivere, se si sa come farlo.