This is NOT a question on plain old boring customization; I actually want to create an program, you know, with source code, etc...
I'm thinking about programming my own media centre interface, and I figured it'd look better if I coded my own splash screen for when the OS is loading.
Note: The media centre interface will be run in X, but this question is regarding what will happen before the X server loads.
Simply, I'd like to make a splash screen application to hide the linux kernel boot messages. Is there a way I can program some animation in to this like some sort of animated progress bar for example? I assume that I won't be able to code any 2D/3D graphics (as that'd require X to be running, right?), so how would I go about generating that?
I'd prefer to do this in C++, but C is also an option.
Note: I'm not looking to use any existing "themes" or anything like that, just interested in the programming side of things.
Update:
Some suggestions have been to use standard images (.bmp, .jpeg, etc), I am not interested in loading images in to an existing application. But obviously I may want to load images in to the boot screen application that I will make.
I'm not tied to a Linux distro, so this can be for anything, although Debian or a Debian-based distro would be nice.
I like the suggestion about loading the X server early and running a loading screen from there, however is there not a more direct approach? Surely you can make a program which hides the boot messages and shows a custom program? Obviously this would be very low level programming, but that's what I'm looking for...
Also, I'm not interested in altering the boot loader (LILO, GRUB, etc).
Update 2:
So far good suggestions have been looking at the source code for applications like splashy and fbsplash. Can anyone better this suggestion?
For the graphical output you can use the Linux framebuffer, for application development you can use gtk which support rendering directly to the framebuffer GtkFB.
For the video and such you can use mplayer which also support rendering to the framebuffer.
For the initialization you have to look around the system used, debian uses a sysv init style initialization http://www.debian-administration.org/articles/212, ubuntu uses upstart.
I'd look into splashy source code. But you will need to code in C.
If you have the skills, you can implement a software based 3D engine (like in the good old days). A simple rotating cube shouldn't be very hard to code and there are tons of tutorials.
The downside is that you will increase the boot time, something not very pleasant in a media center.
Here's the thing: there is a library/kernel patch, fbsplash, that has already been written to do exactly what it sounds like you want to do. It will display an image in place of the normal boot messages, and it can also incorporate a progress bar. When you're trying to do something for which a well-established open-source implementation already exists, there's really no better way to learn how to do it yourself than to look at the source code.
Even if you're looking for something more complicated (say if you want to create some fancier animation than a progress bar), you might be able to start with fbsplash and modify it to suit your needs.
There are several ways you could do this. You could have the X server load very early, and just write a program to display the splash screen. You could also use the framebuffer device. If you are using Intel hardware, or are willing to use the OSS AMD drivers, or Nouveau for Nvidia, you could use kernel mode setting. For this, I would look at Fedora's Plymouth. You could just write a Plymouth plugin to display your splash screen.
The splash screen is simply an image (.bmp, .jpg, etc.) and can be loaded by the boot loader. Since you haven't specified the distribution you're using, look into LILO, grub, or whichever one is appropriate. Check the /boot directory for clues that will direct your search.
If all you want to do is have a nice clean boot sequence with your own splash and absolutely no boot messaging you can do the following:
First, silence grub, boot messaging, and console cursor:
GRUB_CMDLINE_LINUX_DEFAULT = quiet fastboot splash vt.cur_default=1 loglevel=0
GRUB_TIMEOUT = 0
This will very quickly and silently (fade to black) bring you to your login screen, where you can place a splash. Your distro may show it's own splash briefly, which you can change if you like.
This yeilds a professional clean boot sequence, without all the usual linux warts and wrinkles. (Like OSX and Windows).
I personally use Ubunutu with LXDE, and have a clean splashy boot in under 3 seconds, even on older hardware.
Related
This is the context: I am running Debian GNU/Linux and I switch reguarly with desktop environments ("DE" for the next).
My question is simple : I want to know which operation, syscalls or even functions used when I press the keyboard key "Print Screen".
Does the way changes with DE? I.e. do Mate, Gnome, KDE, LXDE or Xfce (etc) used a particular call of their own code or is there a generic syscall?
I think the answer (if any) is not Debian relative but more X or Wayland, is not it?
Thank you in advance for you advices and answers :)
PS: I precise that I read a good part of X lib source code, but did not find something useful.
Print screen itself is definitely not a syscall, but the kernel daemon which gets key presses definitely causes a routine to execute that uses what you would call a "syscall." I put that in quotes, because printscreen probably causes a program to run which is already in kernel space, which means there won't be any system calls to the kernel since you're already there (unless the window manager actually runs at user space, which isn't true for Mac OSX or windows, and I'm assuming for linux as well).
How does it work? It probably works by copying the current display from the screen buffer (region of ram which is DMA'd to your graphics card), and then transforming the pixel representation into a bit map.
The basic principle can be found in the xwd tool.
The code isn't that bad to read. In the simple scenario, it used XGetImage, but if the screen has multiple visual regions, it gets more complex, but the fundamental principle is to use XGetPixel to get screen pixels and XPutPixel to store in the temporary image.
What happens when you press PrtScrn is the same thing, except it may be some other application that starts. Exactly what application depends on what the graphics package is in the distribution (Gnome, KDE, Unity, etc). But internally, they will do something very similar.
Edit:
As Peter points out, if the windowing system is "compositing" (that is, each window draws its own content off-screen, and the graphics hardware combines the output via composition), then the screen capture is required to ask the composition system to render the output off-screen, and then copy that.
For fun i'd like to write code that runs on OSless hardware. I think writing code that will run in a VM (like VMware or virtualbox) would be good. However i don't want to start from scratch. I'd like the C++ runtime to be available. Something that allows me to read/write (maybe FAT32 filesystem code). Graphics for text and if i can graphics for drawing on screen (pixel by pixel. sdl support would be a bonus but not essential).
I'll write my own threads if i want them. I'll write everything else (that i want to use) needed for an OS. I just want a basic filesystem, gfx and keyboard/mouse support.
Take a look at the list of projects on osdev.org - (http://wiki.osdev.org/Projects) - most of these are hobbyist, open-source and range from just-a-bootsector through to proper threads/graphics/terminal support.
Minix3 targets your desires pretty well.
You should definitely take a look at OSKit (links to source code on this site are dead but there is a mirror here). Unfortunately, OSKit has no support for C++ but using this information you may be able to use GCC libraries.
I'm developing a C++ application which will run on a headless server and keep track of some statistics. The application will run in a terminal in a screen session so that I can login over SSH and check those statistics.
Now, what I want to do, is display plots of various data. For that I need pixel-per-pixel access of course, which is not possible with ncurses or S-Lang. I found out about DirectFB (and it's C++ wrappers DFB++ & ++DFB), but can't seem to find conclusive evidence if it is possible to draw graphics with it inside a terminal.
Is DirectFB the way to go? Will it work fine inside a screen session without creating extra windows? If not, is there any library out there that can achieve what I want?
Edit: Ideally, I would of course prefer a library that has some kind of widget support as well, so that I don't have to create tons of classes to emulate text fields/scrollbars/...
You could make your application have a web interface. You could use e.g. Wt or Onion to make your application an HTTP server (or you could make it a FastCgi application), and use SVG (perhaps with Javascript and Ajax tricks) to display vector graphics (or generate a pixel-based PNG or JPEG or GIF image; there are several libraries for that).
I don't think that DirectFB works with SSH, and I believe it is becoming deprecated (for example GTK3 don't support it anymore).
You might also generate Gnu Plot graphics (by generating the appropriate commands), but that is not very interactive.
I don't think that making graphics thru ssh without X make sense, unless you want only ASCII art (which I believe is not the right way for your needs).
I am trying to fix an Audacity bug that revolves around portmixer. The output/input level is settable using the mac version of portmixer, but not always in windows. I am debugging portmixer's window code to try to make it work there.
Using IAudioEndpointVolume::SetMasterVolumeLevelScalar to set the master volume works fine for onboard sound, but using pro external USB or firewire interfaces like the RME Fireface 400, the output volume won't change, although it is reflected in Window's sound control panel for that device, and also in the system mixer.
Also, outside of our program, changing the master slider for the system mixer (in the taskbar) there is no effect - the soundcard outputs the same (full) level regardless of the level the system says it is at. The only way to change the output level is using the custom app that the hardware developers give with the card.
The IAudioEndpointVolume::QueryHardwareSupport function gives back ENDPOINT_HARDWARE_SUPPORT_VOLUME so it should be able to do this.
This behavior exists for both input and output on many devices.
Is this possibly a Window's bug?
It is possible to workaround this by emulating (scaling) the output, but this is not preferred as it is not functionally identical - better to let the audio interface do the scaling (esp. for input if it involves a preamp).
The cards you talk about -like the RME- ones simply do not support setting the master or any other level through software, and there is not much you can do about it. This is not a Windows bug. One could argue that giving back ENDPOINT_HARDWARE_SUPPORT_VOLUME is a bug though, but that likely originates from the driver level, not Windows itself.
The only solution I found so far is hooking up a debugger (or adding a dll hook) to the vendor supplied software and looking at the DeviceIOControl calls it makes (those are the ones used to talk to the hardware) while setting the volume in the vendor software. Pretty hard to do this for every single card, but probably worth doing for a couple of pro cards. Especially for Audacity, for open source audio software it's actually not that bad so I can imagine some people being really happy if the volume on their card could be set by it. (at the time we were exclusively using an RME Multiface I spent quite some time in figuring out the DeviceIOControl calls, but in the end it was definitely worth it as I could set the volume in dB for any point in the matrix)
In Windows XP the Win32 API renders the controls using GDI/GDI+.
Now I'm on 7, so if I use the API's functions, will the rendering automatically be handled by the DWM/WDDM (so by DirectX)? or will it continue to render with GDI?
Or likewise, will an old app written with WinAPI, be rendered with GDI also in Windows 7?
Thank you in advance for the help :)
In my experience, if the Aero display is on everything will render via that system, it just won't be obvious to your application. You'll still render in GDI, but it will be to a back buffer and not directly to the screen buffer (in fact it's more complicated then that). That way your older app can get the benefits of the new features, like the live preview effects, without having to be aware of them.
Really though, your application doesn't really notice a difference. The API is still the same API as before and works as you expect it. There are ways to take advantage of this, but you have to opt in to really use it.
If your application is written to use GDI, then it will continue to use GDI. The underlying implementation has changed quite a bit (as I recall, most hardware acceleration was removed in Vista, and put back in, in a new form, in Win7)
But it won't magically be transferred to Direct2D, no.
On performance front, it is the same old farce and as per usual 'Do Your Own Benchmarking' across OS-es. But, almost a decade old OS for anything GDI still slams Windows7 and plenty of apps will be incredibly more responsive on XP.. Sadness.. especially when you consider that translation of such an old API (as a compatible interface) should be trivial to any new driver or display tech.
Apparently some ops like blitting are supported but look at the result of your target 2D GDI app and judge for yourself..
Here are some observations, but please do your own for a dozen scenarios and compare, especially if it is GDI intensive like a million audio/video apps out there (no wonder iFruit boys are gaining share).
http://www.passmark.com/forum/showthread.php?t=2233
And while you will find all the typical and fluffy MSDN blog explanations that get 'technical' (ie. surface-style nonsense) the reason is very simple: buy a new OS, pull the carpet on old API and complicate it further by allowing new APIs to work with it (but not benefit the old one, easily doable by providing a new dll and .lib ).
For one history lesson and how hard it was to translate GDI calls to Direct2D or use libgdiplus from Mono and derive ideas etc, here is the propaganda:
http://blogs.msdn.com/directx/archive/2009/05/12/2d-drawing-apis-in-windows.aspx