Is it possible to access to the framebuffer in order to put a pixel on the screen from the command line?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












10















I am not sure if it is the only possible way, but
I read that in order to put a single pixel onto the screen at a location of your choice one has to write something into a place called framebuffer.
So I became curious, if it is possible to enter into this place and write something into it in order to display a single pixel somewhere on the screen.










share|improve this question
























  • You didn't specify which OS. Linux?

    – Gilles
    Mar 24 '15 at 23:29











  • Yes , Linux (mint codename rebecca)

    – Abdul Al Hazred
    Mar 25 '15 at 11:05











  • stackoverflow.com/questions/4996777/…

    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Aug 28 '16 at 17:28















10















I am not sure if it is the only possible way, but
I read that in order to put a single pixel onto the screen at a location of your choice one has to write something into a place called framebuffer.
So I became curious, if it is possible to enter into this place and write something into it in order to display a single pixel somewhere on the screen.










share|improve this question
























  • You didn't specify which OS. Linux?

    – Gilles
    Mar 24 '15 at 23:29











  • Yes , Linux (mint codename rebecca)

    – Abdul Al Hazred
    Mar 25 '15 at 11:05











  • stackoverflow.com/questions/4996777/…

    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Aug 28 '16 at 17:28













10












10








10


8






I am not sure if it is the only possible way, but
I read that in order to put a single pixel onto the screen at a location of your choice one has to write something into a place called framebuffer.
So I became curious, if it is possible to enter into this place and write something into it in order to display a single pixel somewhere on the screen.










share|improve this question
















I am not sure if it is the only possible way, but
I read that in order to put a single pixel onto the screen at a location of your choice one has to write something into a place called framebuffer.
So I became curious, if it is possible to enter into this place and write something into it in order to display a single pixel somewhere on the screen.







linux console graphics framebuffer






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 24 '15 at 23:29









Gilles

541k12810941610




541k12810941610










asked Mar 24 '15 at 14:06









Abdul Al HazredAbdul Al Hazred

7,522214372




7,522214372












  • You didn't specify which OS. Linux?

    – Gilles
    Mar 24 '15 at 23:29











  • Yes , Linux (mint codename rebecca)

    – Abdul Al Hazred
    Mar 25 '15 at 11:05











  • stackoverflow.com/questions/4996777/…

    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Aug 28 '16 at 17:28

















  • You didn't specify which OS. Linux?

    – Gilles
    Mar 24 '15 at 23:29











  • Yes , Linux (mint codename rebecca)

    – Abdul Al Hazred
    Mar 25 '15 at 11:05











  • stackoverflow.com/questions/4996777/…

    – Ciro Santilli 新疆改造中心 六四事件 法轮功
    Aug 28 '16 at 17:28
















You didn't specify which OS. Linux?

– Gilles
Mar 24 '15 at 23:29





You didn't specify which OS. Linux?

– Gilles
Mar 24 '15 at 23:29













Yes , Linux (mint codename rebecca)

– Abdul Al Hazred
Mar 25 '15 at 11:05





Yes , Linux (mint codename rebecca)

– Abdul Al Hazred
Mar 25 '15 at 11:05













stackoverflow.com/questions/4996777/…

– Ciro Santilli 新疆改造中心 六四事件 法轮功
Aug 28 '16 at 17:28





stackoverflow.com/questions/4996777/…

– Ciro Santilli 新疆改造中心 六四事件 法轮功
Aug 28 '16 at 17:28










2 Answers
2






active

oldest

votes


















14














yes, outside X-server, in tty, try command:



cat /dev/urandom >/dev/fb0


if colourfull pixels fills the screen, then your setup is ok, and you can try playing with this small script:



#!/usr/bin/env bash

fbdev=/dev/fb0 ; width=1280 ; bpp=4
color="x00x00xFFx00" #red colored

function pixel()
xx=$1 ; yy=$2
printf "$color"
x=0 ; y=0 ; clear
for i in 1..500; do
pixel $((x++)) $((y++))
done


where function 'pixel' should be an answer... write a pixel to screen by changing byte values (blue-green-red-alpha) on x-y offset of device /dev/fbX which is frame buffer for the video-card.



or try one liner pixel draw (yellow on x:y=200:100, if width is 1024):



printf "x00xFFxFFx00" | dd bs=4 seek=$((100 * 1024 + 200)) >/dev/fb0


UPDATE: this code works even inside X-server, if we just configure X to use frame buffer. by specifying fb0 inside /usr/share/X11/xorg.conf.d/99-fbdev.conf






share|improve this answer

























  • There's a couple of dangerous things going on here: the first example appears to write random bytes to a floppy disk, for some reason. The follow up commands use dd which has often been called "Disk Destroy" for specific reasons ... don't go near these commands unless you know what you're doing ...

    – robert
    Mar 27 '15 at 8:31






  • 4





    @robert I think Omar meant /dev/fbX and the /dev/fd was just a typo. And yes, dd is dangerous but so is rm. That doesn't mean it shouldn't be used. It just means that it should be used with care.

    – terdon
    Mar 27 '15 at 11:35











  • ah /dev/fb0 makes more sense! Everybody knows what rm means, but dd is a little more obscure, still think it should carry a health warning.

    – robert
    Mar 27 '15 at 11:37







  • 1





    "yes, outside X-server, in tty, try command:" I do not understand if I got it right, so I tried just opening the terminal and writing "cat /dev/urandom > /dev/fd0" but I only got an error message : "cat: write error: no space left on device". I really do not know how to get out of the xserver.

    – Abdul Al Hazred
    Mar 27 '15 at 15:34











  • ... i called it tty, but it is virtual console, non-gui thing, terminal over all screen, that you reach with ctrl-alt-f1,2,3... or "sudo chvt 1" ... 'no space left' seems like it will be ok, just you are still in X-session.

    – Asain Kujovic
    Mar 27 '15 at 17:03


















0














I just posted this this morning, still investigating why it only works on Raspberry Pis. https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=213964&p=1428891#p1428891



Open /dev/fb0, mmap it so you get a pointer, and it's much faster. Doesn't use X at all but it will happily ignore X, it's just something on the screen.



Oh, from a command line, sort of, you can write to /dev/fb0. But whatever you write at offset 0 will be in the upper left corner so it will immediately scroll off the screen. You could do a for loop in Bash and write a couple thousand times. Or use /dev/urandom. Destroying what's in the screenbuffer, especially while you're in X, is no big deal. As soon as you drag a window over the area X causes an expose event and repaints it. You don't need to kill the power to recover.






share|improve this answer






















    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f192206%2fis-it-possible-to-access-to-the-framebuffer-in-order-to-put-a-pixel-on-the-scree%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    14














    yes, outside X-server, in tty, try command:



    cat /dev/urandom >/dev/fb0


    if colourfull pixels fills the screen, then your setup is ok, and you can try playing with this small script:



    #!/usr/bin/env bash

    fbdev=/dev/fb0 ; width=1280 ; bpp=4
    color="x00x00xFFx00" #red colored

    function pixel()
    xx=$1 ; yy=$2
    printf "$color"
    x=0 ; y=0 ; clear
    for i in 1..500; do
    pixel $((x++)) $((y++))
    done


    where function 'pixel' should be an answer... write a pixel to screen by changing byte values (blue-green-red-alpha) on x-y offset of device /dev/fbX which is frame buffer for the video-card.



    or try one liner pixel draw (yellow on x:y=200:100, if width is 1024):



    printf "x00xFFxFFx00" | dd bs=4 seek=$((100 * 1024 + 200)) >/dev/fb0


    UPDATE: this code works even inside X-server, if we just configure X to use frame buffer. by specifying fb0 inside /usr/share/X11/xorg.conf.d/99-fbdev.conf






    share|improve this answer

























    • There's a couple of dangerous things going on here: the first example appears to write random bytes to a floppy disk, for some reason. The follow up commands use dd which has often been called "Disk Destroy" for specific reasons ... don't go near these commands unless you know what you're doing ...

      – robert
      Mar 27 '15 at 8:31






    • 4





      @robert I think Omar meant /dev/fbX and the /dev/fd was just a typo. And yes, dd is dangerous but so is rm. That doesn't mean it shouldn't be used. It just means that it should be used with care.

      – terdon
      Mar 27 '15 at 11:35











    • ah /dev/fb0 makes more sense! Everybody knows what rm means, but dd is a little more obscure, still think it should carry a health warning.

      – robert
      Mar 27 '15 at 11:37







    • 1





      "yes, outside X-server, in tty, try command:" I do not understand if I got it right, so I tried just opening the terminal and writing "cat /dev/urandom > /dev/fd0" but I only got an error message : "cat: write error: no space left on device". I really do not know how to get out of the xserver.

      – Abdul Al Hazred
      Mar 27 '15 at 15:34











    • ... i called it tty, but it is virtual console, non-gui thing, terminal over all screen, that you reach with ctrl-alt-f1,2,3... or "sudo chvt 1" ... 'no space left' seems like it will be ok, just you are still in X-session.

      – Asain Kujovic
      Mar 27 '15 at 17:03















    14














    yes, outside X-server, in tty, try command:



    cat /dev/urandom >/dev/fb0


    if colourfull pixels fills the screen, then your setup is ok, and you can try playing with this small script:



    #!/usr/bin/env bash

    fbdev=/dev/fb0 ; width=1280 ; bpp=4
    color="x00x00xFFx00" #red colored

    function pixel()
    xx=$1 ; yy=$2
    printf "$color"
    x=0 ; y=0 ; clear
    for i in 1..500; do
    pixel $((x++)) $((y++))
    done


    where function 'pixel' should be an answer... write a pixel to screen by changing byte values (blue-green-red-alpha) on x-y offset of device /dev/fbX which is frame buffer for the video-card.



    or try one liner pixel draw (yellow on x:y=200:100, if width is 1024):



    printf "x00xFFxFFx00" | dd bs=4 seek=$((100 * 1024 + 200)) >/dev/fb0


    UPDATE: this code works even inside X-server, if we just configure X to use frame buffer. by specifying fb0 inside /usr/share/X11/xorg.conf.d/99-fbdev.conf






    share|improve this answer

























    • There's a couple of dangerous things going on here: the first example appears to write random bytes to a floppy disk, for some reason. The follow up commands use dd which has often been called "Disk Destroy" for specific reasons ... don't go near these commands unless you know what you're doing ...

      – robert
      Mar 27 '15 at 8:31






    • 4





      @robert I think Omar meant /dev/fbX and the /dev/fd was just a typo. And yes, dd is dangerous but so is rm. That doesn't mean it shouldn't be used. It just means that it should be used with care.

      – terdon
      Mar 27 '15 at 11:35











    • ah /dev/fb0 makes more sense! Everybody knows what rm means, but dd is a little more obscure, still think it should carry a health warning.

      – robert
      Mar 27 '15 at 11:37







    • 1





      "yes, outside X-server, in tty, try command:" I do not understand if I got it right, so I tried just opening the terminal and writing "cat /dev/urandom > /dev/fd0" but I only got an error message : "cat: write error: no space left on device". I really do not know how to get out of the xserver.

      – Abdul Al Hazred
      Mar 27 '15 at 15:34











    • ... i called it tty, but it is virtual console, non-gui thing, terminal over all screen, that you reach with ctrl-alt-f1,2,3... or "sudo chvt 1" ... 'no space left' seems like it will be ok, just you are still in X-session.

      – Asain Kujovic
      Mar 27 '15 at 17:03













    14












    14








    14







    yes, outside X-server, in tty, try command:



    cat /dev/urandom >/dev/fb0


    if colourfull pixels fills the screen, then your setup is ok, and you can try playing with this small script:



    #!/usr/bin/env bash

    fbdev=/dev/fb0 ; width=1280 ; bpp=4
    color="x00x00xFFx00" #red colored

    function pixel()
    xx=$1 ; yy=$2
    printf "$color"
    x=0 ; y=0 ; clear
    for i in 1..500; do
    pixel $((x++)) $((y++))
    done


    where function 'pixel' should be an answer... write a pixel to screen by changing byte values (blue-green-red-alpha) on x-y offset of device /dev/fbX which is frame buffer for the video-card.



    or try one liner pixel draw (yellow on x:y=200:100, if width is 1024):



    printf "x00xFFxFFx00" | dd bs=4 seek=$((100 * 1024 + 200)) >/dev/fb0


    UPDATE: this code works even inside X-server, if we just configure X to use frame buffer. by specifying fb0 inside /usr/share/X11/xorg.conf.d/99-fbdev.conf






    share|improve this answer















    yes, outside X-server, in tty, try command:



    cat /dev/urandom >/dev/fb0


    if colourfull pixels fills the screen, then your setup is ok, and you can try playing with this small script:



    #!/usr/bin/env bash

    fbdev=/dev/fb0 ; width=1280 ; bpp=4
    color="x00x00xFFx00" #red colored

    function pixel()
    xx=$1 ; yy=$2
    printf "$color"
    x=0 ; y=0 ; clear
    for i in 1..500; do
    pixel $((x++)) $((y++))
    done


    where function 'pixel' should be an answer... write a pixel to screen by changing byte values (blue-green-red-alpha) on x-y offset of device /dev/fbX which is frame buffer for the video-card.



    or try one liner pixel draw (yellow on x:y=200:100, if width is 1024):



    printf "x00xFFxFFx00" | dd bs=4 seek=$((100 * 1024 + 200)) >/dev/fb0


    UPDATE: this code works even inside X-server, if we just configure X to use frame buffer. by specifying fb0 inside /usr/share/X11/xorg.conf.d/99-fbdev.conf







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Nov 3 '16 at 16:01

























    answered Mar 27 '15 at 3:17









    Asain KujovicAsain Kujovic

    1,0191115




    1,0191115












    • There's a couple of dangerous things going on here: the first example appears to write random bytes to a floppy disk, for some reason. The follow up commands use dd which has often been called "Disk Destroy" for specific reasons ... don't go near these commands unless you know what you're doing ...

      – robert
      Mar 27 '15 at 8:31






    • 4





      @robert I think Omar meant /dev/fbX and the /dev/fd was just a typo. And yes, dd is dangerous but so is rm. That doesn't mean it shouldn't be used. It just means that it should be used with care.

      – terdon
      Mar 27 '15 at 11:35











    • ah /dev/fb0 makes more sense! Everybody knows what rm means, but dd is a little more obscure, still think it should carry a health warning.

      – robert
      Mar 27 '15 at 11:37







    • 1





      "yes, outside X-server, in tty, try command:" I do not understand if I got it right, so I tried just opening the terminal and writing "cat /dev/urandom > /dev/fd0" but I only got an error message : "cat: write error: no space left on device". I really do not know how to get out of the xserver.

      – Abdul Al Hazred
      Mar 27 '15 at 15:34











    • ... i called it tty, but it is virtual console, non-gui thing, terminal over all screen, that you reach with ctrl-alt-f1,2,3... or "sudo chvt 1" ... 'no space left' seems like it will be ok, just you are still in X-session.

      – Asain Kujovic
      Mar 27 '15 at 17:03

















    • There's a couple of dangerous things going on here: the first example appears to write random bytes to a floppy disk, for some reason. The follow up commands use dd which has often been called "Disk Destroy" for specific reasons ... don't go near these commands unless you know what you're doing ...

      – robert
      Mar 27 '15 at 8:31






    • 4





      @robert I think Omar meant /dev/fbX and the /dev/fd was just a typo. And yes, dd is dangerous but so is rm. That doesn't mean it shouldn't be used. It just means that it should be used with care.

      – terdon
      Mar 27 '15 at 11:35











    • ah /dev/fb0 makes more sense! Everybody knows what rm means, but dd is a little more obscure, still think it should carry a health warning.

      – robert
      Mar 27 '15 at 11:37







    • 1





      "yes, outside X-server, in tty, try command:" I do not understand if I got it right, so I tried just opening the terminal and writing "cat /dev/urandom > /dev/fd0" but I only got an error message : "cat: write error: no space left on device". I really do not know how to get out of the xserver.

      – Abdul Al Hazred
      Mar 27 '15 at 15:34











    • ... i called it tty, but it is virtual console, non-gui thing, terminal over all screen, that you reach with ctrl-alt-f1,2,3... or "sudo chvt 1" ... 'no space left' seems like it will be ok, just you are still in X-session.

      – Asain Kujovic
      Mar 27 '15 at 17:03
















    There's a couple of dangerous things going on here: the first example appears to write random bytes to a floppy disk, for some reason. The follow up commands use dd which has often been called "Disk Destroy" for specific reasons ... don't go near these commands unless you know what you're doing ...

    – robert
    Mar 27 '15 at 8:31





    There's a couple of dangerous things going on here: the first example appears to write random bytes to a floppy disk, for some reason. The follow up commands use dd which has often been called "Disk Destroy" for specific reasons ... don't go near these commands unless you know what you're doing ...

    – robert
    Mar 27 '15 at 8:31




    4




    4





    @robert I think Omar meant /dev/fbX and the /dev/fd was just a typo. And yes, dd is dangerous but so is rm. That doesn't mean it shouldn't be used. It just means that it should be used with care.

    – terdon
    Mar 27 '15 at 11:35





    @robert I think Omar meant /dev/fbX and the /dev/fd was just a typo. And yes, dd is dangerous but so is rm. That doesn't mean it shouldn't be used. It just means that it should be used with care.

    – terdon
    Mar 27 '15 at 11:35













    ah /dev/fb0 makes more sense! Everybody knows what rm means, but dd is a little more obscure, still think it should carry a health warning.

    – robert
    Mar 27 '15 at 11:37






    ah /dev/fb0 makes more sense! Everybody knows what rm means, but dd is a little more obscure, still think it should carry a health warning.

    – robert
    Mar 27 '15 at 11:37





    1




    1





    "yes, outside X-server, in tty, try command:" I do not understand if I got it right, so I tried just opening the terminal and writing "cat /dev/urandom > /dev/fd0" but I only got an error message : "cat: write error: no space left on device". I really do not know how to get out of the xserver.

    – Abdul Al Hazred
    Mar 27 '15 at 15:34





    "yes, outside X-server, in tty, try command:" I do not understand if I got it right, so I tried just opening the terminal and writing "cat /dev/urandom > /dev/fd0" but I only got an error message : "cat: write error: no space left on device". I really do not know how to get out of the xserver.

    – Abdul Al Hazred
    Mar 27 '15 at 15:34













    ... i called it tty, but it is virtual console, non-gui thing, terminal over all screen, that you reach with ctrl-alt-f1,2,3... or "sudo chvt 1" ... 'no space left' seems like it will be ok, just you are still in X-session.

    – Asain Kujovic
    Mar 27 '15 at 17:03





    ... i called it tty, but it is virtual console, non-gui thing, terminal over all screen, that you reach with ctrl-alt-f1,2,3... or "sudo chvt 1" ... 'no space left' seems like it will be ok, just you are still in X-session.

    – Asain Kujovic
    Mar 27 '15 at 17:03













    0














    I just posted this this morning, still investigating why it only works on Raspberry Pis. https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=213964&p=1428891#p1428891



    Open /dev/fb0, mmap it so you get a pointer, and it's much faster. Doesn't use X at all but it will happily ignore X, it's just something on the screen.



    Oh, from a command line, sort of, you can write to /dev/fb0. But whatever you write at offset 0 will be in the upper left corner so it will immediately scroll off the screen. You could do a for loop in Bash and write a couple thousand times. Or use /dev/urandom. Destroying what's in the screenbuffer, especially while you're in X, is no big deal. As soon as you drag a window over the area X causes an expose event and repaints it. You don't need to kill the power to recover.






    share|improve this answer



























      0














      I just posted this this morning, still investigating why it only works on Raspberry Pis. https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=213964&p=1428891#p1428891



      Open /dev/fb0, mmap it so you get a pointer, and it's much faster. Doesn't use X at all but it will happily ignore X, it's just something on the screen.



      Oh, from a command line, sort of, you can write to /dev/fb0. But whatever you write at offset 0 will be in the upper left corner so it will immediately scroll off the screen. You could do a for loop in Bash and write a couple thousand times. Or use /dev/urandom. Destroying what's in the screenbuffer, especially while you're in X, is no big deal. As soon as you drag a window over the area X causes an expose event and repaints it. You don't need to kill the power to recover.






      share|improve this answer

























        0












        0








        0







        I just posted this this morning, still investigating why it only works on Raspberry Pis. https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=213964&p=1428891#p1428891



        Open /dev/fb0, mmap it so you get a pointer, and it's much faster. Doesn't use X at all but it will happily ignore X, it's just something on the screen.



        Oh, from a command line, sort of, you can write to /dev/fb0. But whatever you write at offset 0 will be in the upper left corner so it will immediately scroll off the screen. You could do a for loop in Bash and write a couple thousand times. Or use /dev/urandom. Destroying what's in the screenbuffer, especially while you're in X, is no big deal. As soon as you drag a window over the area X causes an expose event and repaints it. You don't need to kill the power to recover.






        share|improve this answer













        I just posted this this morning, still investigating why it only works on Raspberry Pis. https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=213964&p=1428891#p1428891



        Open /dev/fb0, mmap it so you get a pointer, and it's much faster. Doesn't use X at all but it will happily ignore X, it's just something on the screen.



        Oh, from a command line, sort of, you can write to /dev/fb0. But whatever you write at offset 0 will be in the upper left corner so it will immediately scroll off the screen. You could do a for loop in Bash and write a couple thousand times. Or use /dev/urandom. Destroying what's in the screenbuffer, especially while you're in X, is no big deal. As soon as you drag a window over the area X causes an expose event and repaints it. You don't need to kill the power to recover.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 12 at 16:18









        Alan CoreyAlan Corey

        594




        594



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f192206%2fis-it-possible-to-access-to-the-framebuffer-in-order-to-put-a-pixel-on-the-scree%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?