C/C++ Draw graphics on display without Xorg

Spartrekus

Daemon

Reaction score: 152
Messages: 1,150

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.
 
OP
OP
Spartrekus

Spartrekus

Daemon

Reaction score: 152
Messages: 1,150

Check out DirectFB and SDL. Would you elaborate on why would you need that.
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.
 

Bobi B.

Well-Known Member

Reaction score: 142
Messages: 345

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.
 
OP
OP
Spartrekus

Spartrekus

Daemon

Reaction score: 152
Messages: 1,150

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:

olli@

Well-Known Member
Developer

Reaction score: 306
Messages: 361

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. ;)
 
OP
OP
Spartrekus

Spartrekus

Daemon

Reaction score: 152
Messages: 1,150

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
 

Bobi B.

Well-Known Member

Reaction score: 142
Messages: 345

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

Spartrekus

Daemon

Reaction score: 152
Messages: 1,150

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 ;)
 

olli@

Well-Known Member
Developer

Reaction score: 306
Messages: 361

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.
 
OP
OP
Spartrekus

Spartrekus

Daemon

Reaction score: 152
Messages: 1,150

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...
 

ondra_knezour

Aspiring Daemon

Reaction score: 197
Messages: 762

There was vgl(3) library, but it probably still isn't supported with new vt console driver. At least four years ago it was not.

I remember some developer asking on mailing lists circa two years back if anyone is using it and no replies, so it is probably clinically dead.
 
OP
OP
Spartrekus

Spartrekus

Daemon

Reaction score: 152
Messages: 1,150

I never heard of this one.

I remember an alternative to svgalib, but I cannot find out its name. really very old.
 

kpedersen

Daemon

Reaction score: 535
Messages: 1,438

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.
 

aragats

Daemon

Reaction score: 515
Messages: 1,246

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
 
OP
OP
Spartrekus

Spartrekus

Daemon

Reaction score: 152
Messages: 1,150

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.)
 

ralphbsz

Daemon

Reaction score: 1,160
Messages: 1,870

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.
 

aragats

Daemon

Reaction score: 515
Messages: 1,246

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.
 

felselva

New Member

Reaction score: 10
Messages: 7

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/10/06/example-run-an-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.
 

ralphbsz

Daemon

Reaction score: 1,160
Messages: 1,870

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.
 
Top