[Linux] group for linux REBOL users
Here is a nice GRUB2 startup image with cosmic ship flying to Saturn with grub.cfg on how to display the image during GRUB2 menu display: http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/debian-cd_info.tar.gz
The image and .cfg are easily extractable from the archive.
It would be fun to grow Linux with no X at all! Thoughts anyone?
Here's an article all about it: http://www.terminally-incoherent.com/blog/2007/05/21/a-day-without-x/
And Kaj already mentioned DirectFB.
Andreas, I'm interested in direct video hardware programming under linux. So the following text from a page you mentioned is most interesting to me:
One of the details I left out in the above overview is how clients actually render under wayland. By removing the X server from the picture we also removed the mechanism by which X clients typically render. But there's another mechanism that we're already using with DRI2 under X: direct rendering. With direct rendering, the client and the server share a video memory buffer. The client links to a rendering library such as OpenGL that knows how to program the hardware and renders directly into the buffer. The compositor in turn can take the buffer and use it as a texture when it composites the desktop. After the initial setup, the client only needs to tell the compositor which buffer to use and when and where it has rendered new content into it. This leaves an application with two ways to update its window contents: 1. Render the new content into a new buffer and tell the compositor to use that instead of the old buffer. The application can allocate a new buffer every time it needs to update the window contents or it can keep two (or more) buffers around and cycle between them. The buffer management is entirely under application control. 2. Render the new content into the buffer that it previously told the compositor to to use. While it's possible to just render directly into the buffer shared with the compositor, this might race with the compositor. What can happen is that repainting the window contents could be interrupted by the compositor repainting the desktop. If the application gets interrupted just after clearing the window but before rendering the contents, the compositor will texture from a blank buffer. The result is that the application window will flicker between a blank window or half-rendered content. The traditional way to avoid this is to render the new content into a back buffer and then copy from there into the compositor surface. The back buffer can be allocated on the fly and just big enough to hold the new content, or the application can keep a buffer around. Again, this is under application control. In either case, the application must tell the compositor which area of the surface holds new contents. When the application renders directly the to shared buffer, the compositor needs to be noticed that there is new content. But also when exchanging buffers, the compositor doesn't assume anything changed, and needs a request from the application before it will repaint the desktop. The idea that even if an application passes a new buffer to the compositor, only a small part of the buffer may be different, like a blinking cursor or a spinner.
I'm also very interested in direct framebuffer rendering on Linux. Is DirectFB the most advanced framework for such use?
DocKimbel - read also the wayland link above --- at least the text I quoted here.
It mentions DRI2.
(I didn't read about DRI2.)
Here's a DRI2 page (a lot of unknown terms): http://www.x.org/wiki/DRI2
Looking at the DRI2 Wikipedia's page, it seems it still needs X to run?
In computing, the Direct Rendering Infrastructure (DRI) is an interface and a free software implementation used in the X Window System to securely allow user applications to access the video hardware without requiring data to be passed through the X server. Its primary application is to provide hardware acceleration of the Mesa implementation of OpenGL. It has also been adapted to provide OpenGL acceleration on a framebuffer console without an X Server running. http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure_(DRI)
X with many DRI apps would be fun!!!
From that wpedia page: "[DRI] is now part of the X.Org Server."
So it seems that DRI and DRI2 are way to go.
DirectFB allows applications to talk directly to video hardware[...] "The [DirectFB] library allows developers an alternative to a full X Window System (X11) server[...]" http://en.wikipedia.org/wiki/DirectFB
Unrelated thing: "The Linux framebuffer (fbdev) is a graphic hardware-independent abstraction layer to show graphics on a computer monitor, typically on the console. The word framebuffer means a part of video memory containing a current video frame, and the Linux framebuffer means \u201caccess method to the framebuffer under the Linux kernel\u201d, without relying on system-specific libraries such as SVGALib or another user space software." http://en.wikipedia.org/wiki/Linux_framebuffer
More DRI info: "Wayland display server, hosted by freedesktop.org and developed by several X.Org developers, both addresses criticisms of X by replacing it completely and works directly with the hardware via DRI. It is planned for Wayland to eventually replace X in Ubuntu and Fedora, the two most popular Linux distributions. Wayland handles backward compatibility with X by optionally running an X.org server as a client, which can be rootless (having one Wayland window per X client)." http://en.wikipedia.org/wiki/X_Window_System
And more DRI and DirectFB: "Other competitors attempt to avoid the overhead of X by working directly with the hardware. Such projects include DirectFB. The Direct Rendering Infrastructure (DRI), which aims to provide a reliable kernel-level interface to the framebuffer, may make these efforts redundant." (same article)
So this clears all issues for me.
Faster DEs: "Q: How much faster is fluxbox compared with XFCE? A: Fluxbox will certainly load much faster after the login screen, and will consume probably 1/2 to 1/3 of the RAM that xfce will, but if you have lots of RAM you probably won't notice much speed difference after the loading process. However, if you only have 256MB of RAM fluxbox is the way to go..." http://forums.linuxmint.com/viewtopic.php?f=142&t=30599 (Untested by me)
aptitude search dri|grep DRI p driconf - DRI configuration applet p libgl1-mesa-dri-dbg - Debugging symbols for the Mesa DRI modules p x11proto-xf86dri-dev - X11 DRI extension wire protocol
with my nvidia card: :( driconf Xlib: extension "XFree86-DRI" missing on display ":0.0". Screen "0" is not direct rendering capable.
nouveau.freedesktop.org nvidia drivers wiki doesn't include the word DRI :(((
Ah. It includes a DRM word.
DirectFB looks outdated to me. It seems to support only old graphic cards.
My latest gnewsense 2.3 doesn't include DRI.
So it seems I need to build my own CLFS cross-lfs.org ... Though I didn't search for Linux distros supporting DRI.\
DRI links: http://dri.freedesktop.org/wiki/Links--- includes OSes, Linux distros, cards supporting DRI
AltME. I installed RHEL-based 64-bit Linux. And yum shows no 32-bit emulation libs. Anyone knows is it possible to set up RHEL64 for 32-bit altme? The disto is ScientificLinux http://scientificlinux.org
As far as I know, DRI requires 3D support. DirectFB supports 2D hardware and drivers. It can be combined with OpenGL
It's quite possible that the OpenGL combination requires DRI
It seems 3D is optional at DRI.
REBOL Folks. How to fix a font in REBOL editor---it's unreadable!!! http://s017.radikal.ru/i401/1202/f0/b05d8abc5412.png
lsb_release -a;uname -a No LSB modules are available. Distributor ID: gNewSense Description: gNewSense GNU/Linux 2.3 (deltah) Release: 2.3 Codename: deltah Linux greenmeadow 2.6.24-30-generic #1 SMP Thu Jan 12 02:39:14 UTC 2012 i686 GNU/Linux Ok
sudo apt-get install xfonts-100dpi xfonts-75dpi [sudo] password for gouslar: Reading package lists... Done Building dependency tree Reading state information... Done xfonts-100dpi is already the newest version. xfonts-75dpi is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Ok
It's completely impossible to work with such a renderer of an editor.
I'll try to install R3---maybe it's more OK.
I recommend using an external editor. R2's internal editor is not very good.
R3 does not have an internal editor.
I'd be happy to attach an external editor to [Edit] Button in R2 or R3.
I usually do it the other way around. Find a favorite editor and attach R2 or R3 to it.
That all is imperfect. OK.