C Draw graphics on display without Xorg

Hello,

With clean install (kernel.txz and base.txz) without installation of Xorg, which opportunities might be being given to draw graphics (no acceleration, lines, box,...) on the display?

In C language, would be best.

Thank you and best regards,
Sp.
 
Because I would like to run graphical simulations on a computer without being locked behind a graphical library.
It should be simple, running on low specs computers, in particularly.
Well, using either library will create a dependency on it, right? Perhaps SDL would be better, as apart from a dedicated framebuffer, you can also run SDL apps on X-Windows, Windows and Mac.
 
Well, SDL is a dependency, surely.
Directfb as well. Actually Directfb might work on Apple, since it is Unix.
Windows is less important.

Graphic acceleration is less important.

Any way to avoid libraries would be good, in all cases. framebuffer is a way on linux and unix, but it cannot be applied/ported easily to other types.

Just remembering a bit,... that X11R5 or X386 used a minimum implementation, at prehistoric ages.

NOTE:
To plot a X-Y function, we certainly do not need graphical acceleration or any kind of wayland. I presume.
I did plot a simple function with Xorg (library), quite simple to use X11 today, but it may be simpler without X.

x11-graphsin.png
 
Last edited:
Unfortunately, the DirectFB project is abandoned (see this article (link), for example), and SDL requires a backend itself, which can be an X11 server or a native framebuffer (like Linux framebuffer). Unfortunately, nowadays this works well only on embedded hardware. In the “old days” (last century) there was SVGALib, but this is now defunct, too. Some graphics cards support the VESA standard, so you can at least use VESA graphics modes, and on some platforms you can use the EFI framebuffer. But all of this is non-portable. The only graphics modes that probably work on every PC are the standard VGA modes, which are 640 × 480 pixels @ 16 colors and 320 × 200 pixels @ 256 colors. Not very nice on a modern monitor with >= 1080p resolution.

Oh, by the way, you can use ASCII graphics, of course. ;)
 
In other word, quite a dead end for no X.

Black and white for Y/X is fair enough ok actually. Maths...

In DOS, it is very easy with mem, and one can draw points and lines, without any library. but it requires Dosbox.
Of course the kernel won't enable similar ways, other than fb, like old timer?

reg.h.ah=0; reg.h.al=19;
int86(0x10,&reg,&reg);
adr=_MK_FP(0xA000,0x0);
memset(adr,int c , 64000u);
adrpixel += py*320+px;
...

Thank you anyhow
 
Well, you can always move to JavaScript and use HTML5 canvas for raster and svg for vector. Browsers are pretty common nowadays :)

You are kidding, good joke, I am sure because from your posts, you have visibly long experience in programming.

;=) java and html is definitely ideal for a clean installation.

About libs, java is good one ;)
 
In DOS, it is very easy with mem, and one can draw points and lines, without any library. but it requires Dosbox.
Of course the kernel won't enable similar ways, other than fb, like old timer?
Well, basically you can do the same with FreeBSD (after all, SVGALib did that, too). This requires root privileges. You can use the vidcontrol(1) command to switch modes; the following command will list all modes (text and graphics) supported by your graphics BIOS:
vidcontrol -i mode < /dev/ttyv0
To access the actual graphics memory, you can use /dev/mem (see the mem(4) manual page). Of course you have to be very careful, because you can easily crash your machine if you do something wrong.
 
Thank you.
Sounds good to me, after all, it can be run on a test machine.
By the way, in C, we can crash anyhow with root the whole machine.

I am interested actually...
 
I never heard of this one.

I remember an alternative to svgalib, but I cannot find out its name. really very old.
 
I asked similar (for OpenBSD on daemonforums) just before Christmas. I was porting my 3D software renderer to run directly on frame buffer.

http://daemonforums.org/showthread.php?t=10855

Yes, I had issues with the new vt terminal mode for the FreeBSD but it still works with the old one. That said, it could be me doing something wrong ;)

I was a little disappointed by the state of drawing on *nix without X11. I unfortunately got busy so didn't get time to pursue it further.

This was quite handy for me for getting vgl to work. https://github.com/gonzoua/freebsd-pi/blob/master/share/examples/libvgl/demo.c

My fancy renderer screenshots / source here :D: (https://github.com/osen/software-3d-renderer)
I haven't yet merged the framebuffer stuff in yet.
 
devel/qt5 supports framebuffer out of the box. Of course, it's not a small simple library, but may be really convenient for complex projects.
You can run your Qt5 GUI program without X:
Code:
QT_QPA_PLATFORM=bsdfb myqtprogram
 
I asked similar (for OpenBSD on daemonforums) just before Christmas. I was porting my 3D software renderer to run directly on frame buffer.

http://daemonforums.org/showthread.php?t=10855

Yes, I had issues with the new vt terminal mode for the FreeBSD but it still works with the old one. That said, it could be me doing something wrong ;)

I was a little disappointed by the state of drawing on *nix without X11. I unfortunately got busy so didn't get time to pursue it further.

This was quite handy for me for getting vgl to work. https://github.com/gonzoua/freebsd-pi/blob/master/share/examples/libvgl/demo.c

My fancy renderer screenshots / source here :D: (https://github.com/osen/software-3d-renderer)
I haven't yet merged the framebuffer stuff in yet.

VGLInit(SW_VGA_MODEX); can be converted to sthg closer to original commands.
Likely VGL is not needed after all.

let's remember
reg.h.ah=0; reg.h.al=19;
int86(0x10,&reg,&reg);
adr=_MK_FP(0xA000,0x0);
memset(adr,int c , 64000u);
adrpixel += py*320+px;
...

(@Osen: Nice.
That 's a cool programming training, ideally for educational purpose of new students: https://github.com/osen/software-3d-renderer
... Btw, sometimes ... young programmers start their first programming experience with microsoft visual basic, followed by Python, C++ and C# (this under Win 7-8, Win 10 OS). Maybe, FreePascal would be even a nice first begin, as well. Pascal is pretty nice, even for small graphical approaches Ex.)
 
I think Kivy (python drawing and user interface library) can work on a frame buffer.

Bu why are you averse to just using X? Today's graphics hardware is very complex. About 30-40 years ago, graphics hardware was relatively simple. It was either a terminal (like the Tektronix 4014), and you sent it sequences of characters over RS232 to draw points, lines, markers, and so on. Or it was memory-mapped (I used various boxes, like a Grinnell on a VAX), where one calculated the memory addresses of pixels and wrote to memory to turn them off and on. That was 30 years ago, when a graphics device consisted of a few hundred TTL chips, with a few thousand gates.

Today, real-world graphics devices are extremely complex, and have millions to billions of gates. Drawing on them is extremely efficient, very fast, and very complex. That means that you will need complex and device-specific libraries to communicate with them. That's the reality; denying that reality will not make it go away. Those libraries also have another great advantage: they give us device independence. Something like X virtualizes the underlying hardware, and gives you a uniform interface, independent of whether the hardware is NVidia, Radeon, or a 30-year old framebuffer on a HP workstation. This is good.

You are better off embracing today's way of doing things, rather than trying to construct a dream world. Download and install X (it is not that huge, and quite reliable and fast). Get the programming manuals for X (there used to be an about 10-volume set of manuals that most Unix programmers had on their bookshelf, but today it's all online), and start drawing.
 
But why are you averse to just using X? Today's graphics hardware is very complex.
I agree with all the above in general, but there are exceptions.
For example, among embedded systems. And sometimes an ARM SBC's GPU simply is not supported by OSs, e.g. the BeagleBone Black's GPU. In such cases X uses frame buffer anyway.

A real life example: I involved in a commercial project based on the BBB, and I have to use Qt5 for a number of reasons. Since it supports the frame buffer directly, we eliminated using X as an unneeded layer.
 
I don't know the specifics of FreeBSD yet, but I did what you are trying on Linux. On Linux, you get a buffer using the libraries for DRM and GBM. On FreeBSD, it's probably similar (https://www.freebsd.org/cgi/man.cgi?query=drm&sektion=7&manpath=freebsd-release-ports).

Look online for "headless OpenGL". Here is an example: https://blogs.igalia.com/elima/2016...opengl-es-compute-shader-on-a-drm-render-node

Even if you don't want OpenGL/EGL, you will find examples using OpenGL/EGL. You just need to skip the OpenGL part of the examples.
 
Absolutely agree, and I should have listed that as an exception. Matter-of-fact, I was looking at using Kivy directly to framebuffer on a Raspberry Pi a few months ago, and got it to kind of work once (and then the project got abandoned due to lack of time). Still, I didn't attempt to do graphic operations directly on the framebuffer; instead I used Kivy to draw some simple things.

Just for a historical note: Before the mid-80s, I already did some graphics, on micros (6809 with video output from RAM), personal machines (Commodore 2001, Apple II), minicomputers (VAXen), and mainframes (with Tek4014 attached). On the VAX we had a Grinnell frame buffer that was murder to use and unreliable (often would lock up the Unibus), and later a dedicated 11/750 with an Evans&Sutherland video output device. Then workstations started making things even more complex, initially MicroVAXen with their VWS windowing system. Programming any of those was an enormous amount of work, and no two things used the same interface. It was brutal. Then X showed up, and suddenly there was a light at the end of the tunnel: We could do most of our work with a single programming interface! Simplicity and convenience had been achieved. I remember taking a graphics library (UG = "Unified Graphics" out of SLAC, used by the TopDrawer graphical data analysis program), and writing an X backend for it; took a few weeks, but was a great investment, since I could stop maintaining and fixing the half dozen other backends.

And this is why I get upset when people like Spartrekus glibly want to throw great software (like X) out the window, just because of their prejudices. Yes, it can be fun as an educational exercise to learn how to do graphics directly. But just because it can be done doesn't mean that it should be done, nor does it mean that you should do it the hard way directly to the hardware. If he wants to learn to draw points, lines, markers, and figures, he should go to a good common denominator, and in Unix land that's something like OpenGL, Qt, or raw X.
 
Back
Top