Resizescreen è un’utile script che ci consente di aumentare la risoluzione massima del 25% o di più direttamente da terminale. 

Ubuntu in Netbook
Sono ancora molti gli utenti che utilizzano Netbook, personal computer portatili compatti, ottimi soprattutto per navigare in internet. Molti user utilizzano nei netbook distribuzioni / ambienti desktop leggeri come ad esempio Lubuntu / LXDE o XFCE in grado di fornire un’ottimo sistema operativo in grado di richiedere poca memoria ram.
Essendo dispay molto ridotti (di norma da 10 pollici con risoluzione da 1024×600) può capitare di trovare dei problemi con alcune applicazioni dove troviamo caratteri o immagini troppo piccoli. Per risolvere questo problema possiamo utilizzare Resizescreen, utile script che ci consente di aumentare temporaneamente la risoluzione massima del nostro display da riga di comando.

Resizescreen è un’utile script che va ad operare in xrandr consentendoci di poter gestire la risoluzione del nostro monitor o in display collegati, aumentandone temporaneamente la risoluzione massima di una percentuale. Esempio possiamo aumentare la risoluzione massima del 25% attraverso un semplice comando da terminale, volendo possiamo anche impostare una scorciatoia da tastiera per attivare velocemente l’aumento della risoluzione.

Semplice e funzionale, Resizescreen è semplicissimo da scaricare e utilizzare basta digitare da terminale:

wget https://github.com/theredbaron1834/Scripts/raw/master/resizescreen
chmod +x resizescreen
sudo mv resizescreen /usr/bin/resizescreen

ora possiamo utilizzare Resizescreen dal nostro terminale, basta digitare il comando -s seguito dalla percentuale della risoluzione massima da aumentare.

per conoscere tutte le varie opzioni basta digitare:

resizescreen -h

Resizescreen in Ubuntu - Opzioni

Esempio se vogliamo aumentare la risoluzione massima del 25% basterà digitare da terminale:

resizescreen -S 25 

Per rimuovere Resizescreen basta digitare:

sudo rm /usr/bin/resizescreen

e confermiamo.

Ringrazio il nostro lettore Ales. per la segnalazione

  • peccato che non sia (e mi sa che sara’ qualcosa di molto remoto) il supporto all’ipod nano touch.

  • EnricoD

    Io ho avuto problemi con la luminosità sul net ma solo con distribuzioni basata su ubuntu… (lubuntu, xubuntu, mint xfce ad es)
    il problema che avevo era che la luminosità massima raggiungibile cambiava ogni volta che lo avviavo e random…
    certe volte era troppo luminoso, altre, invece, era troppo poco luminoso…
    quindi può essere una buona soluzione…
    Invece con Arch non sto avendo problemi del genere… boh

    • Kim Allamandola

      A naso son problemi di ACPI, marca+modello può aiutare se vuoi indagare 🙂

      • EnricoD

        asus eeepc 1011px versione 2gb. Proprio quello nella foto! XD .. si, erano problemi legati ad acpi, ai tempi, quando segnalai il mio problema, in sezione richieste si trovano le risposte, mi aiutò Erika a risolvere, bastava cambiare dei valori in un file di configurazione e tutto tornava a funzionare normalmente… 😉 sta cosa non mi accade su arch

        • Kim Allamandola

          Bé si può vedere che differenze ci sono a tema .config di Linux 🙂 ma con Arch su una macchina così modesta non trovi un po’ fastidiosi i tempi di build? Ai tempi lasciai Gentoo prima e FreeBSD poi proprio per i tempi e magagne di build!

          • EnricoD

            no, neanche molto…
            arch è l’unica con cui mi diverto 🙂

  • Ruminante marziano

    Anzichè mescolare tutto in /usr/bin è meglio tenere i propri script/esperimenti in /usr/local/bin (o qualcosa del genere nella propria home e nel PATH). /usr/bin se lo gestisca il package manager, sennò si fa solo casino.

    • Kim Allamandola

      /usr/local come /mnt è un po’ in declino da parecchi anni, semplicemente non va più di moda…

      Cmq per un wrapper a xrandr IMO ~/.myenv/script o ~/.myenv/bin va più che bene, solo che troppi oggi non sanno manco cosa siano i dot-files, figuriamoci ad organizzarli… Poi senti tante urla per comportamenti anomali e trovi che han configurazioni stratificate nei secoli…

    • In realtà sarebbe opportuno inserire nella variabile di ambiente PATH ~/.local/bin e porre i binari li ^_^

      • Kim Allamandola

        usare ~/.local per binari è cosa assai rara, in genere si usa per icone/lanciatori personali ma come bin non l’ho ancora vista 🙂

        Avere una dir sola con tutti i propri dot-files di rilievo (shell, vim/emacs, tmux/screen, …) è utile per mantenere un ambiente portabile e comodo da replicare/pulire, .local non lo vedo molto comodo visto che è già usato da altri… Un gusto personale cmq!

        • Agno

          Per icone, lanciatori e cestino si usa ~/.local/share/
          Anche io uso ~/.local/bin

          • Kim Allamandola

            Posso curiosare per cosa? Come mantieni (se le mantieni) le home sincronizzate/come pulisci la home nel tempo?

            Io in genere concentro tutto in un tree personale .myenv che poi linko nella home dove serve così ho solo una cosa da mantenere quando ripulisco la home e altre personalizzazioni (gconf/gsettings/lanciatori ecc) le gestisce Ansible, un tempo replicavo con makeself ma tra bin, emacs ecc è diventato decisamente pesante 🙁

        • luca020400

          Oppure si mette tutto in ~/bin/ e si aggiunge questo nel .profile

          if [ -f ~/bin/ ]
          then export PATH=~/bin:$PATH
          fi

          • Kim Allamandola

            magari -d 🙂

          • luca020400

            Si scusa
            if [ -d “$HOME/bin” ] ; then
            PATH=”$HOME/bin:$PATH”
            fi

        • In realtà local nasce dall’esigenza di effettuare delle modifiche in /usr/ senza effettuarle realmente non è un caso che ci sia appunto ./.local/share/ che corrisponde a /usr/share, ergo se si vuole aggiungere qualcosa in /usr/{bin,sbin} la sintassi è appunt ~/.local/{bin/sbin} come è anche vero che in teoria tutte le configurazioni dei programmi dovrebbero stare dentro ~/.config/ e non sparpagliate per tutta la home dir 🙂

          • Kim Allamandola

            Hem, non ho capito cosa intendi: /usr/local è nata per essere un tree locale (iow non un export nfs) al sistema almeno stando alla storia dell’fhs, ~/.local oggettivamente non ricordo quando è comparso ma non c’ho mai visto dentro bin, mi pare sia più una trovata di FreeDesktop che non qualcosa di sistema, ~/.config è roba molto recente, credo non più di 6 anni fa, per questo molti non lo usano…

          • e chi ha parlato di /usr/local/ ? 😛
            Se per te 6 anni significa recente allora lasciamo perdere 🙂

          • Kim Allamandola

            “nasce dall’esigenza di effettuare delle modifiche in /usr/ senza effettuarle realmente” 😛

            6 anni dico che è recente per il tasso di cambiamenti nell’fhs, per dire /media è roba “recente” /run, /srv idem, /sys un pelo meno ma di poco… ‘Somma dal 1/1/1971 ad oggi i cambiamenti sono stati relativamente pochi 😛

            .local se ricordo bene è si intesa come una “/usr” personale ma non è proprio “standard”, è un’idea di FreeDesktop che ha proposto un pacco di altre cose tipo ~/.exec (mai vista usata da nessuno) .cache, .config ecc. Dal mio modo di vedere sono dirs “ad uso e consumo” degli ambienti desktop e come tali non mi piace metterci nulla di mio se non l’indispensabile poiché quando pulisco la home pulisco anche loro, diciamo che non sono proprio “sotto il mio controllo”…

  • heron

    Questo script in realtà è una semplificazione del comando xrandr.

    L’ho fatto notare allo sviluppatore e mi ha fornito questa risposta:

    Yeah, I call xrandr in this script. This is more of an easy to use thing (for me). No needing to remember how much to set the panning, ect. If I just run resizescreen, it will boost the vidoe size to 25%. Or I can pass -s $Percent, and it will boost it. For me, I run have LXQT auto run resizescreen -s 35 every time I boot. You can get it to go as high, or low as you want. Any integer, even a negitive if you want to drop the size a bit.

    It is really just a simple wrapper for xrandr.

    Actually, that post is one I use to reference all the time, as I always forgot the correct command. Which is one of the reasons I made the first iteration of this script, so I know longer need to care about find it :). Also, this script is now “portable”, only needed xrandr. Doesn’t matter what screen size I go to, resizescreen will boost it. So if I move to a new netbook with a 1366×768 screen, and I want it a bit bigger. I can run resizescreen, and get an instant 25% boost.

    Granted, this isn’t much use to you, as you known said command for your screen. But the commands on that page only work on 1024×600. If you look back in the git history, you will see it used to pretty much just run that command, to give me a 1360×768 screen (with the commands for other sizes commented out, for reference), or back to stock if run will boosted. However, I have hope to soon get a new laptop, with a likely bigger screen, but I known I will still want to use it as you can really never have enough screen real estate. So I redid it to what you see now. It will grab your current screen res, and use that to get the needed –scale and –panning for your requested % increase.

    ————

    In pratica speravo che funzionasse in maniera diversa da xrandr, perché senza i driver appropriati non funziona.

    E invece chiama xrandr, quindi boh io continuo a non vederne l’utilità, se non la sintassi più corta xD

  • ciao! con Fedora 17 se ridimensiono la finestra ottengo sì una “risoluzione” maggiore ma il mouse non va nella parte bassa dello schermo, diciamo che se lo schermo è 1024×600 e con questo script do un “resizescreen -s 25” si ferma attorno al 600 e al 1024 e non è possibile andare ad utilizzare quel 25% in più.
    Qualcuno ha una soluzione?

  • Silvio

    Come si fa per tornare alla risoluzione precedente?

No more articles