I want to write a simple program to capture complete desktop screenshot in pure C on linux i.e no QT or Xlib
Simple: reimplement Xlib inside your program, or at least the portion of it you need to grab the screen. You should start by reading about the X protocol.
Edit: Maybe you should read the Wikipedia page on the X protocol before the formal specification. What you want is to send a GetImage X request, as documented on page 61 of the PDF linked above.
Related
I am new to Linux system calls.My question is do we have a system call in Linux to plot points on screen.I googled it but could not find any simple explanation for it. I want to write a simple C program in Linux that directly plot a point on screen without the help of a C graphics library.
If there is no such system call how can I create my own system call to plot point on screen?
The lowest level hardware independent graphics interface on linux is the framebuffer. This is manipulated by writing to a device node (generally /dev/fb0) which is the equivalent of a system call, since it is a means of sending requests to the kernel. So this does not require any libraries.
A common approach seems to be to mmap() a chunk of user space memory representing the screen to /dev/fb0 and then manipulating that. There are some ioctl() calls to get information about the framebuffer display. A good starting place for information would be the docs in the kernel source -- src/Documentation/fb is a whole directory, see e.g. "framebuffer.txt" and "api.txt" there. There are a few tutorials and such around if you look online. It doesn't matter particularly which kernel version source you look at -- the last revision of "api.txt" was 2011 and "framebuffer.txt" a decade before that (so the interface is very stable).
Note that you can't use the framebuffer from within X. If you want to do graphics stuff within X, you have to use at least Xlib, or a higher level library built on that.
#define MAX_SCREEN_AREA 100
int Gotoxy(int x, int y)
{
char essq[MAX_SCREEN_AREA]={0}; // String variable to hold the escape sequence
sprintf(essq, "\033[%d;%df", y,x);
printf("%s", essq);
return 0;
}
Try this.
I am creating a tick-based simulation in C, currently running on Mac OS X 10.8.4.
At the moment after each tick, I am printing out the entire world representing in ASCII to the terminal, using ANSI escape codes to move the cursor to the correct place.
I would like to transition to a graphical based representation of the world instead of using the terminal window. What would be a good library use? Also, what is the accepted way of performing multiple updates to the screen per second in this library?
I would use SDL since it is cross compatible with most OS and mature.
Also check these examples for 2D animations in order to perform the screen updates you need.
Obviously, this information is available in xorg.conf so I could try to parse this file. But is there a way to achieve this using Xlib calls (+ extensions) only?
Thanks,
PMJ
It must be possible, because I know the program xdpyinfo can do it. At first, I was going to suggest executing that from within your program and parsing the output. That shouldn't be necessary, though, since the source of xdpyinfo is freely available.
It looks like if you have a (Display*) variable (and you will, because pretty much every X11 function call requires one), you can call these wonderful macros to get interesting data, including ServerVendor and VendorRelease. That should cover the "graphic adapter" portion of your quest.
As for the monitor name, according to xdpyinfo.c, this is governed by XF86VidModeGetMonitor() which is part of an X11 extension. This returns a XF86VidModeMonitor structure which will reveal vendor, model, and other juicy data.
Run xdpyinfo-- if that program can query the data, so can your program.
How would I change a pixel on a display, in C?
Assume NOTHING: I am using a linux machine from console to do this. I do not want to use GUI toolkits or frameworks to draw the pixel. I do not want to draw the pixel in a window. I want to draw the pixel directly to the screen.
EDIT: I have a screen. I'm on a laptop running linux from console. I'd prefer a solution not using X as I'd rather learn how X works than how to use X.
If theres more information, ask, but don't assume. I'm not trying to build a GUI, and that was the main purpose of blocking assumptions as I don't want people to assume I'm doing things the long way when in reality I'm just tinkering.
EDIT 2: You may use any X11 related libraries provided that you can explain how they work.
If we really assume nothing, can we even assume that X is running? For that matter, can we even assume that there is a video card? Perhaps Linux is running headless and we're accessing it over a serial console.
If we are allowed to assume a few things, let's assume that Linux has booted with framebuffer support. (It's been a couple years since I worked with Linux framebuffers, I may get some of the details wrong.) There will be a device created, probably /dev/fb or /dev/fb0. Open that file and start writing RGB values at an offset, and the screen will change, pretty much regardless of anything: text console, graphical console, full-fledged desktop envrionment, etc. If you want to see if framebuffer support is working, do dd if=/dev/zero of=/dev/fb on the command line, and the display should go all black.
C doesnt have any graphics capabilities - you'd need to use a third party library for this.
You cannot assume a display in C. There is literally no way to do what you ask.
Edit: Okay, you have a display, but again, there's not a whole lot you can get from there. The point is that there are a TON of competing standards for graphics displays, and while some of them (VGA interfaces, for example) are standardized, a lot of the others (display driver interfaces, for example) are NOT. Much of what X (and other display device drivers, such as Windows or the like) do, is have specific interface code for how to talk to the display drivers; they abstract out the complexity of dealing with the display drivers. The windowing systems, though, have HUGE libraries of complicated and specific code for dealing with the display drivers; the fact that these things are relatively transparent is an indication of just how much work they've put into these things over time.
Very primitive and making a lot of assumptions:
fd = open("/dev/fb0", O_RDWR);
lseek(fd, 640*y+x, SEEK_SET);
write(fd, "\377\377\377\377", 4);
In reality, you would use mmap rather than write, and use the appropriate ioctl to query the screen mode rather than assuming 640xHHH 32bpp. There are also endian issues, etc.
So in real reality, you might use some sort of library code that handles this kind of thing for you.
I suppose you could paint to the terminal program that you are using as your console. All you have to do is figure out which one that is and look it up.
Whoops I assumed a terminal. :P
I think what you are looking for is information on how to write to the frame buffer. The easiest way would be to use SDL and render to the frame buffer, or else use GTK+ with DirectFB, although that goes against your edict on not using toolkits or frameworks.
I am stuck with the problems like, reading text from a specific location (x=10, y=5) on the console window.
Where can I find a detail tutorial on Win32 API Console mode programming in C?
You'd need to use ReadConsoleOutput(). Beware of the ambiguity in a coordinate like (10, 5). It could be relative from the console window upper-left corner. Or from the screen buffer. You'd probably need to make the buffer size the same as the window size to avoid this. SetConsoleScreenBufferSize().
These console functions are not wrapped by the C-runtime. The SDK documentation is quite decent, start here.
On MSDN, see the section on Character Mode Applications.
You can read text from the screen using the ReadConsoleOutputCharacter function.