If your concern is looks, just save effort and go with Qt/GTK+ and pick a style/theme/look&feel pack that's less flashy, or realise this is a personal preference and that the toolkit with greater flexibility in this regard will get your users with various tastes and not tie you all to the limitations of basic X plus whatever you recreate - it smacks of Not Invented Here syndrome. Also being as these Qt/GTK+/WxWidgets are cross-platform, they are the abstraction layer you're talking of writing, or just have 2 layers, so you require less specific changes in less places to be ported about.

There is nothing to say that Linux must load an existing, conventional driver to operate any existing video machinery. However, there is the matter of prevention of userspace processes from directly touching hardware. It is possible to use special root privileged userspace code to access hardware, and thus create so-called userspace drivers. This might be how you would use your existing code, although I'm not sure how it would all fit together. Conventionally, one would use the /dev/port &/or /dev/mem facilities to gain access to the hardware, but this would become quite sub-optimal when used as intensively as you would need to do to create a GUI. It would certainly make your optimized assembler code sub-optimal. It may or may not be easy to translate your existing code into a proper Linux device driver, but I suspect it would significantly alter the API you presently use to access it. It sounds like your VGA library may be built as x86 real-mode code, and there are probably implications surrounding that, as well, since Linux is a fully protected mode OS on x86 hardware.
Unlike Windows, Linux itself does not consider the video hardware to be an integral part of the OS. It is quite common for embedded systems to be completely headless. Indeed, the desktop GUIs that we commonly use are simply userspace applications running fully independently from the Linux OS. By convention only, X is the standard method of crafting GUIs under Linux. The X servers we generally use on desktop Linux hosts is typically built on local video hardware supported by drivers that are also independent of the X server.
While I don't doubt the optimization embedded in your code, I would urge you to explore the quality of the code that has been created in Linux drivers for the same hardware. It has the benefit of many years of testing, scrutiny, and upgrades by people who do actually know some things, too.

--- rod.

Hi there,

I'm just trying to address all the helpful contributions in one post. Let's see if that works.

Oh, you mean these details? Well, if the message structure is fixed, you have to use the same structure member for different purposes depending on the particular context. That's where the API reference kicks in - I always have it in reach when I'm coding Win32 applications.

I'm curious about that, thank you.

I avoid C++ whenever I can help it, and rather use plain C. That's why I probably favor GTK. However, I may have a look at QT as well.

I'm not talking about modern GPUs - I'm talking about using basic GUI elements that work even on a plain vanilla VGA at 640x480x16 with no hardware acceleration.

Yes, and that's fine for ordinary desktop systems. For an embedded system that runs one particular application, however, the line separating kernel space from user space is irrelevant, and the only thing that counts is what the developer thinks is good. And under that assumption, I was planning to give the application full access to the VGA controller. "Full" means not controlled by the kernel.

It was, originally. But assuming the process is granted unrestricted access to the VGA hardware, it could run fine under a modern OS if it doesn't claim the VGA subsystem to be "my own".

Thanks for the compliment, but: No, I want my code to run fully privileged on my hardware.

I wish you all a merry Xmas.
[X] Doc CPU

No offense, but that should be rather old device by now (unless it is custom hardware, or device is extremely specialized). As far as I know, some degree of hardware acceleration is pretty much standard by now in anything that has a display. There are cellphones that support shaders, and credit-card sized device can run Quake 3 at 1080p with antialiasing. In 2000 that was a science-fiction. A card that could run Doom 3 (GeForce 3) was released 10 years ago, and used device like that should be dirt-cheap by now. Technologies move extremely quickly, and it is quite easy to miss the moment when some impressive technology becomes "old" (speaking from experience).

So I do not think that it is reasonable to keep "vanilla VGA" with 4bit color in mind when developing gui controls. It might be more reasonable to offload worries about acceleration and speed onto abstraction layer provided by OS, and concentrate on programming instead. Still, the choice is yours. Perhaps you develop extremely specialized software for extremely specialized hardware or something. Or perhaps you don't.

Hi there,

yes, maybe, but I do have some old boards like that here, and I do want to put them to some use again.

I'm talking about hardware that is some ten to fifteen years old - and yet too good to throw away.

And you didn't notice that I stressed it's not an application for the wide public, but a specialized embedded system?

Pity I can't watch the youtube video because I banned that domain. Then again, maybe it's not a pity. And yes, it is a very specialized application, which you should always assume when the keyword "embedded" appears.

[X] Doc CPU

Doc CPU,

I will add my voice to the GTK+ recommendation. I think you will find it worthy of anytime you invest.

To the later hardware oriented question, let me remind you to review the structure of the linux kernel. Rather than looking for ways to keep the kernel away from certain address ranges, you might want to consider how you can adapt your objectives into those of the kernel itself. Kernel drivers and modules are not hard to originate and they have full access to the hardware, and might be considered your very own abstraction layer. Open source and Linux offer new possibilities and/or options.

I appreciate your approach to this transition and wiliness to do the heavy lifting. Spend some time with the kernel before you decide on tooling. Linux is more.

James,

If you're running Linux, it is quite relevant. The OS enforces, abetted by the MMU hardware, restriction of access to the hardware. When it does grant access, it isn't accessible in the same way you might if running a real-mode (x86) OS. If you need to use real-mode style access, you won't be able to do it from Linux userspace.

--- rod.

Hi there,

it is not, because in that scenario, one assumes that the application (or part of it) runs at the same privilege level as the kernel itself. Direct access to non-standard hardware, for example, is a basic requirement for many embedded applications. Now a VGA controller isn't exactly non-standard hardware, but I still want to keep up the principle and have that piece of hardware for direct and exclusive access.

Yes, I know. But I assume there is a way to make a deal with the OS, like "grant me full access to a certain resource and keep off it."

Oops. That's the first time in this thread I become uncertain: Why not? If I write a kernel mode driver for certain hardware, it does have direct access to the hardware it's written for. I just want to employ the same principle here - only that the code claiming and getting these rights isn't a separate module, but instead part of the application's executable, so that access remains exclusive to that particular application.
Of course that part would have the status of a device driver, as far as privileges are concerned. That was so obvious for me I didn't mention it.

Sure is. And yet, I don't want to mix some of my code into the kernel, I want peaceful coexistence of my own module and the kernel that cares for the rest, so that they have similar rights, but don't interfere because they never try to access the same resources.

[X] Doc CPU

FWIW, there is kernel mode Linux: http://www.linuxjournal.com/article/6516 , http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/ .

Hi there,

great hint, seems exactly what I'm looking for (though I still believe there's a solution with a standard kernel). Thank you!
*bookmark*

[X] Doc CPU

Has also FUSE: http://fuse.sourceforge.net/ been mentioned here ?

Hi there,

no, AFAIS not. That's also a very interesting solution, but for a different problem, is it? ;-)

[X] Doc CPU

I haven't looked into details; there is a kernel part in the solution which you can modify, and then you'll do what you want from userspace, sticking to UNIX "everything is a file" philosophy.

The modified kernel part may talk to your VGA HW.

The above have been my quick thoughts on the problems you are trying to solve - no more than that.

Code running in userspace (applications) has restrictions that differ from code running in kernel space (the kernel, its drivers whether loadable or built-in). Thats part of how Linux ensures security. If you want to get the benefit of (true) Linux, you are bound by that which makes it strong. The only way to give your code the status of a device drvier is for it to be a device driver.

It is quite feasible to create userspace drivers that use the facilities provided by Linux to gain full access to hardware. Its just that the nature of that access is through defined mechanisms such as the ioperm() facility, the /dev/port() and /dev/mem() system calls. Re-writing your VGA driver to use these facilities probably isn't a huge deal, and the use of mmap() to access large blocks of video memory is implemented in a very efficient way.

Sergei, I'm not sure how fuse can be exploited as any aid to accessing hardware from userspace. I've used it before, and never saw that as a part of it's role. Can you expand on that a bit?

--- rod.

EDIT: written while above articles were being posted.

Hi there,

yea fine, but what is it that makes it a device driver? Can't a device driver be part of an application, like, for instance, a dynamic library?

Right, and depending on how efficient these mechanisms are in terms of speed, they may or may not slow down the "pseudo-driver" noticeably. Access to I/O ports is not that crucial, but fast memory access is. I'm concerned that using a combination of /dev/mem and mmap() might turn out to be a brake block. But maybe it's acceptable for the project. I'll know in a few weeks. :-)
Modifiying my existing code to use these features would indeed be easy.

As I understand it, the kernel part is providing the file API, and the actual work is done in user space. This wouldn't allow for kernel style hardware access. That's why I said, fine idea, but for a different problem.

[X] Doc CPU